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Preface 



"New systems generate new problems." 
— Murphy's Technological Laws #17 



0.1 An Important Event 

On October 19, 1998, the Executive Council of the Association for Computing 
Machinery (ACM) approved a document titled "The Software Engineering Code of Ethics and 
Professional Practice". A few months later, the Board of Governors of the Computer Society of 
the Institute for Electrical and Electronic Engineers (lEEE-CS) did the same. That double 
approval successfully completed an undertaking officially begun almost six years before as part 
of a larger effort to "establish software engineering as a profession". 

That double approval was an important event in both professional ethics and the history 
of professions. Software engineers design, construct, test, and maintain software. There are today 
at least a million "software engineers" around the world.^ They already form a global occupation 
to an unusual degree even in this age of globalism. SofbA/are engineers daily work together 
across national borders and even across oceans. What a team of software engineers did in 
Califomia during their worlday may be passed to a team in India v\to, eight hours later, may 
pass it on to a team in Ireland v\to, at their day's end, return it to Califomia Because software 
can traverse vast distances almost instantaneously and at almost no cost, international 
cooperation is dependent only on technical infrastmcture and justified tmst in the technical skill 
and professionalism of those v\to must cooperate. With the increasing demand for software, 
especially for the conqiex software on v\Mch lives and property often depend, both the number 
of software engineers and their inpjrtance seem liMy to increase substantially for decades to 
come. Theirs is a profession about v\Mch everyone should know. But theirs is especially a 
profession about v\Mch those v\to mate technology or science policy should know. Much of 
what is, or will be, technologically possible depends on sofbA^are, its cost, and the standards to 
which it can be built— that is, upon v\tot software engineers do and how they do it 

Software engineering is also a profession that has provided us an opportunity to leam 
much about how an occupation becomes a profession A great part of dr^ng the Software 
Engineering Code was done by email; and much of that email has survived For many provisions 
of the Code, vve need not guess how they came to be or v\tot the drafters' intent was. We have a 
record of the stages the provisions passed through, with the drafters' explanation of each change. 
Though the record is inconplete (as records generally are), it is (as far as I can tell) fuller than 
ariy other we have for the writing of a profession's code of ethics. We have the materials for a 
"case study" of unusual depth, one of special interest for at least three reasons. 

First, the Code is plainly not a mere variation of some other— certainly not of the IEEE' s 
or ACM' s. It is a large code (almost 3000 words). It has an unusually long preamble, maity novel 
provisions, and some innovations in stmcture. 

Second, the Code does not seem liMy to be a mere academic exercise, no sooner 
adopted than forgotten Conpjting societies outside North America (including some in China, 
India, and Europe) have adopted it The code has already been translated into a half dozen 
languages.^ A number of international corporations (e.g., Rcytheon) have adopted it as a standard 



of conduct for those working on software.^ It has been included in a fair number of recent texts 
in conpjter ethics/ 

Third, a "professional soddy", such as the American Medical Association or the 
American Bar Association, generally exists long before the correspjnding professional code. The 
code is the work of one standing organization— if only, as with the Code of Ethics of the Worid 
Federation of Engineering Organizations, an organization consisting of other organizations. 
Software engineering has no such organization The ACM and lEEE-CS generally operate 
independently. In many respects, they are con^Detitors (even though the overi^ in merrfcersMp is 
substantial and the two organizations cooperate on marry projects). Neither is a professional 
society (strictly speaking), that is, an organization the membership of v\Mch consists entirely (or 
even largely) of men±)ers of one profession The membership of lEEE-CS includes marry 
conpjter engineers (those who focus on corrpjter hardware and "machine language"), 
computer scientists (for example, those interested in the mathematics of computing), and 
information systems specialists (graduates of business school interested only in the application of 
software). The membership of the ACM is equally diverse. Software engineers are a minority, 
though a large one, in both organizations. The cooperation of the ACM and lEEE-CS in writing 
the Software Engineering Code is therefore an interesting anomaly. But it is also an important 
anomaly. The ACM and lEEE-CS are not only large organizations in absolute terms; they are 
also the world's two largest organizations of those who make their living studying, engineering, 
managing, and teaching about software (though some of their members are merely interested in 
software). Each has close to a hundred thousand members, many outside North America.^ What 
these two organizations do can have inpjrtant consequences for corrpjting-related activities 
everyv\tere. 

Because the Code was written as part of a larger undertaking expressly designed to mate 
"software engineering" a profession (v\tether a part of engineering or an independent profession 
was unclear), those interested in "professionalization" should find much in the history of the 
Software Engineering Code interesting. The two societies formed a 'Joint Steering Committee 
for the Establishment of Software Engineering as a Profession" (the Steering Committee). The 
Steering Committee divided the work of making software engineering a profession among three 
task forces: one to define the body of knov\dedge; a second, to define the curriculum to teach that 
body of knov\dedge; and the third, to define a code of ethics that should guide ^plication of the 
body of knov\dedge.^ The task force concerned with the Code soon took the acronym "SEEPF' 
(for reasons explained in 3.4). Though n^^ focus here is SEEPP, I could not avoid tdling some of 
the story of the Steering Committee and of the other two task forces, much as one must speak of 
parents and siblings v\ten recounting the life of an individual. Studying SEEPP from start to 
finish should, then, give insight into how one profession formed, v\^ it formed, and v\^ it 
adopted a code of ethics. 

That is one reason I have written this book, to tell an inpjrtant story. The second reason 
is to learn from that story how better to go about drafting a cocte of professional ethics. Several 
times a year, a professional society contacts the Center for the Study of Ethics in the Professions 
(CSEP) at the Illinois Institute of Technology to ask whether it can provide assistance with 
writing or revising their code of ethics. Because I am CSEF s "codes esq^ert", I answer marry of 
these inquiries. Overtime, CSEFs librarian and I have turned much of wtet. I used to say into a 
webpage with a small tabliogr^±y.' We add to it v\tenever we find ariything that seems liMy to 
be useful. This book should be an inportant addition to that habliography. At last, we wiU be able 



to offer would-be writers of a code the chance to see the problems that stand in the way of 
organizing such an undertaking, the way provisions get worked out the interplay between big 
ideas and local politics, and so on. And, of courses, this book will be available to many who 
might not think to check our website. 

The third reason I have written this book is to provide later generations of software 
engineers insight into how to interpret the Code— and how to change it— that can only come 
from what they call "documentation". The more we know about how a code came to be, the 
more we can appreciate its strengths and weaknesses, the compromises on which it rests, and the 
problems it solved or put off (and those the drafters never imagined). Knowing such things 
should help software engineers understand the Code and therefore help them to interpret it, to 
revise it when revising seems wise, and to fend off unnecessary revisions. This book should be as 
useful to software engineers trying to act ethically as to those (scholars, engineers, or anyone 
else) trying to understand professions. 

0.2 Plan of the Book 

This book has three main parts. Part One (chapters 2-6) describes events that led from the 
first use of the term "software engineer" to Version 1 of the Code. Part Two (chapters 7-10) 
describes the process of repeated revision by which what was Version 1 on January 1, 1997 had 
become Version 4 by year's end. Part Three (chapters 11-12) completes the story of writing the 
Code and sketches the Code's subsequent dissemination. In addition to these three parts, this 
Preface, and the usual Bibliography and Index, this book includes a short introductory chapter 
(Chapter 1) and an Epilogue. Chapter 1, designed for the specialist in professional ethics rather 
than for ordinary readers, explains the assumptions on which this book rests, especially its 
understanding of "ethics" and "profession". Most of the Epilogue is also designed for the 
specialist. It offers reflections on some ethical problems raised by writing this case study, by the 
method used to reconstruct what happened, and by the decision to create an archive for relevant 
documents. However, section 13.2 is for the general reader— or, at least, for anyone interested in 
drawing from this history practical lessons for writing a code of professional ethics. 

Seven of the chapters include an appendix. Six of these are versions of the code 
corresponding to the version under discussion in the chapter (from the early Version through 
the final Version 5.2). But one Appendix (Chapter 7) is a provision-by-provision table 
comparing Version 1 with twelve other codes of ethics (six from engineering and six from 
computing). These appendices should be useful for following events. This book is in part a 
biography of the Code (one covering "the early years"). There are therefore many references to 
particular provisions. While the provisions are (I hope) always quoted when needed, their 
context cannot always be and sometimes the context matters in ways hard to foresee. I have 
included these appendices in part to make it easier to follow discussion of particular provisions 
(and to see their context). 

I have also included these appendices because I foresaw another use for them. This book 
is, in part, about writing a complex technical document. Those interested in technical writing 
may find much in the writing (and rewriting) of the code familiar— but not adequately caught in 
other studies of the writing of technical documents. Here are preserved, not all stages of the 
document, but at least a good many of them, along with the running commentary of authors and 



critics. All the documents cited, and many not cited, are archived at the CSEP's library and at 
http://hum.iit. edu:8080/aire/mainindex.html. 

This book is a work of history. History is not a chronicle ("one damn thing after 
another") but a narrative, that is, a description of events related in a way that makes sense 
(generally, because the later events seem to grow out of the earlier). Every history must have a 
first event and a last— as well as a relatively small number of events in between (whether 
arranged in simple chronological order or in some more complicated way). Anyone wishing to 
write history must choose among events. Without that choice, the history would be too large to 
write; and, being too large to write, not be history at all. Though there is no algorithm for 
choosing among events, some choices will be better than others, that is, provide a more 
comprehensive or comprehensible narrative; some choices will be worse; and some, merely 
different, emphasizing one interesting subject at the expense of others. Presupposing such a 
choice, no history can be more than one version of the past. Other versions are possible. No 
version is wrong, so long as consistent with the evidence we have. One version can, of course, be 
better than another for some purpose— or even overall. 

Analogies between divinity and authorship are not without justification. Writing has its 
privileges. But, whatever the privileges, infallibility is not one of them. I have certainly made 
errors here, perhaps most often when I persevered in a conclusion against the advice of those 
whose judgment I respect (as I have now and then). I have therefore tried to provide enough 
detail to allow a reader to draw a different conclusion. I have, however, consigned some of the 
detail to endnotes to maintain narrative flow. 

This book should be read through quickly the first time, ignoring the endnotes— and, for 
those who only want the story, ignoring the first chapter and epilogue as well. If the book seems 
worth reading again, even in part, it should be read more slowly, consulting the endnotes more or 
less as one might stop to read wall plaques while touring a strange city ("Here the Bastille once 
stood"). A good book is a battlefield where intelligent armies clash in the half light their big guns 
make overhead. Books die when they can no longer recruit readers into one or another of those 
armies. 

0.3 Acknowledgements 

While few books are written alone, this one is even more of a group effort than most. I 
came to the writing of history with few credentials. I was not trained as a historian. Indeed, the 
only history courses I took in college (too long ago) were in the history of philosophy and 
political thought. I never took a course even in the philosophy of history, much less in 
historiography or method. What I know about writing history I have learned by reading, by 
talking to historians (including my wife before she became a lawyer), and by trying my hand at a 
few small studies, at best a good way to begin learning a difficult art.^ I have, therefore, 
benefited from having a historian on the board that advised me through four years of research 
and writing. A friend of long standing. Lew Erenberg, another historian, Mped me find a 
suitable title for the book— and consoled me v\ten I worried that I might not krDw v\tot I was 
doing, telling me in effect: "No general' s plan ever survived contact with the enerr^^." 

I had a board of advisors to consult throughout this work David Coogan, Humanities 
(Technical Writing), IIT (2001-2003); Donald Gotterbam, Conpjter and Information Sciences, 
East Tennessee State University; Gerald Engd, Conpjter Science and Engineering, University 
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of Connecticut; Ilene Bumstein, Computer Science, HT; Peter Whalley, Sociology and 
Anthropology, Loyola University of Chicago; Thomas Misa, Humanities (History), IIT; Ullica 
Segerstrale, Social Sciences, IIT; Vivian Weil, CSEP, IIT (chair); and Elizabeth Quinlan, 
CSEP's Librarian. In addition to what I gained from them individually (acknowledged 
elsewhere), there was one benefit that no one of them could provide alone. I learned much just 
listening to their debates concerning whether I should do "this" or "that". Sometimes competing 
opinions teach more than any one opinion, however sound. 

I have found two members of the advisory board, the sociologists (Segerstrale and 
Whalley), especially helpful in understanding the limits of interviewing even for the purposes to 
which I eventually limited my interviewing and helpful as well in shaping interviews so that I 
could benefit in the limited way I came to consider appropriate. Though, in general, philosophers 
know even less about interviewing sources than about writing history, that was not my problem. 
I had learned the basics of interviewing during a few months as a reporter for my college 
newspaper (a career cut short by my inability to write news reports in a form the editor could 
use). In the late 1980s, I learned more about interviewing while carrying out sixty interviews as 
part of a study of relations betweens managers and engineers.^ I conducted most of those 
interviews with Tom Calero, a veteran of marry such studies, then a member of IIT's Stuart 
School of Business, since retired That was good training for interviewing, but not for the 
interviewing I undertook for this book. Calero and I were not interested in the past so much as 
the present We did not have to worry about the accuracy of memory. 

Writing about the living has some advantages. Four of the living I studied (Bumstein, 
Engd, Gotterbam, and Weil) were members of the advisory board Lite the other advisors, they 
had a duty to read v\tot I wrote. Their comments certainly helped me mate this a much more 
nuanced study than it would otherwise have been Several other participants in writing the Code 
(people v\to had no such duty) also read one or more versions of the manuscript in part; and two 
(Ed Mechler and Keith Miller) read the v\tole thing. Lite members of the acMsory board, they 
corrected errors of spelling, grammar, style, and fact and challenged some of niy interpretations. 
They also urged me to say more about some sutgects about v\MchI did not say enough or did not 
thidk to say ariything. I have not always agreed with what they advised, but I have always been 
thankful for the advice. Advice would be command if we could not decline to follow it 

This book would have been inpjssible without two grants from the National Science 
Foundation (NSF). One, a small start-up grant allowed CSEFs research group to follow events 
as they unfolded and to collect a basic archive during the crucial years 1995-97. A second grant 
(SES-01 17471), much larger than the first (2000-2005) paid for the expenses of the interviews, 
including some in England, half of a sabbatical year, and another semester of writing rather than 
teaching (Spring 2004). It also made possible cooperation between CSEP and the Software 
Engineering Ethics Research Institute at East Tennessee State University, v\Mch transferred to 
CSEP marry significant documents that might otherwise have been lost including marry 
documents from before 1995 or after 1997. Several interviewees, especially Ed Mechler arri 
George Sigut also saved inpjrtant documents now safe in the archive. The second NSF grant 
has allowed Liz Quinlan, CSEFs Librarian, to oversee the archive, hdiing to put it in an 
electronic form I could use. (Her successors, especially Kelly Laas, have carried on the work.) In 
this, they have had the help of several of IIT's graduate students in conpjter science or 
engineering: Vishal Mehta, Vikram Modi, and Sushma Shankar, but espededly Mayur Naik, 
Anoop Kabra , and K^l DiksMt That the archive is now "on line" is due in substantial part to 
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Ophir Frieder, Director of IIT Information Retrieval Lab (and IITRI Chair Professor of 
Computer Science at IIT), who is allowing use of his lab's AIRE (Advanced Information 
Retrieval Engine) application as our search engine. Jefferson Heard, doctoral student and lab 
member, did the work of coding and programming the engine to "crawl" our data. 

I should also thank IIT for granting a sabbatical leave for the academic year 2002-2003, 
and my interviewees who, despite lapses of memory, not only taught me much about parts of the 
writing of the Code of which they knew more than I did but also about software engineering (and 
software engineers). I too had the help of a graduate student, Tony Spencer (Sociology, 
Northwestern University), who assisted at many of the early interviews— and whose untimely 
resignation I considered a substantial loss.^° 

The length of a book' s acknowledgements is— or, at least, should be— a function not only 
of memoiy for debts owed but of the patience of readers and the putiisher's budget I have, I 
fear, now reached the limits of both. 

Chicago, 2009 



NOTES 

^ There seems to be no hard number for "software engineers" (though I have heard 

estimates as high as 3,000,000 world-wide). The 1,000,000 used here is merely n^^ conservative 
guess based on the opinions of those v\to seemed to have the best chance of being right We are 
unliMy to have a b^ter estimate until we have some way to track sofbA/are engineers, not only 
those viito graduate with the ^Dpropriate degree but also (v\tet are still far more numerous) those 
v\to "corwert" from conpjter science, engineering, or some other discipline some time in their 
career. 

^ http//seeri.etsaedu/Codes^defaultshtm (August 23, 2004). 

^ For a partial list of organizations that have adopted the code, see: seeri.etsaedu/ 

se_code_adopter/organizations.asp (April 17, 2004). 

' See, for exanqie Sara Baase, A Gift of Fire: Social, Legal, and Ethics Issues for 

Computers and the Internet, 2"^ edition (Pearson Education, Inc.: Upper Saddle River, ]N[J, 2003); 
Terrell Ward Bynum and Simon Rogerson, Computer Ethics and Professional Responsibility 
(Blackwell: Oxford, 2004); Michael J. Quinn, Ethics for the Information Age (Pearson Addison 
Wesley: Boston, 2004): Herman T. Tavani, Ethics and Technology: Ethical Issues in an Age of 
Information and Communication Technology (John Wiley and Sons: Hoboken, NJ, 2002). While 
Bynum-Rogerson (pp. 170-179) and Tavani (pp. 322-329) print the code complete, both Baase 
(pp. 439-445) and Quinn (pp. 370-379) omit the initial statement of principles ("Short Version") 
and the final credits (neither of which is necessary for teaching the code). 

^ On April 17, 2004, the lEEE-CS claimed 100,000 n^nbers; the ACM, 75,000. 

Deducting for duplicates, the total comtaned membership is (probably) between 125,000 and 
150,000, a large number— but not as large as the 175,000 usually dted 

^ Neither the Steering Committee nor the body of knov\dedge task force seems to have 

thought of the code of ethics as part of the body of knowledge— though, of course, it is (or, at 
least, should be). 

' See www.iitedu/departments/csep/PublicWWW/codes^bliogr^±y (April 21, 2004) . 

^ The most inp^rtant of this work in history are: "What can we learn ty looking for the 

first code of professional ethics?" Theoretical Medicine and Bioethics 24 (2003): 433-454; 
"Three Myths about Codes of Engineering Ethics", IEEE Technology and Society Magazine 20 
(Fall 2001): 8-14 & 22; "Writing a Code of Ethics by E-Mail: Adventures with Software 
Engineers", Science Communication 21 Qune 2000): 392-405; "Are 'Software Engineers' 
Engineers?" Philosophy and the History of Science 4 (October 1995): 1-24; "An Historical 
Introduction to Engineering Ethics", Science and Engineering Ethics 1 Qanuary 1995): 33-48; 
"Righting the History of Mathematics, or How Sausage Was Made," Mathematical Intelligencer 
16 (Fall 1994): 21-26; and "The Ethics Boom: What and Why", Centennial Review 34 (Spring 
1990): 163-186. 1 do not count my work in the history of philosophy, not even my favorite (but 
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widely ignored): Actual Social Contract and Political Obligation: A Philosopher's History 
through Locke (Edwin Mellen Press: New York, 2002). 

^ The results of this research, funded by the Hitachi Foundation, are to be found in niy 

"Better Communications between Engineers and Managers: Some Ways to Prevent Ethically 
Hard Choices", Science and Engineering Ethics 3 (April 1997): 171-213. 

^ ° The original plan was for me to pair for interviews with a colleague in Social Sciences, a 
young political sociologist with considerable experience in interviewing, but he proved 
unexpectedly hard to replace after he left IIT unexpectedly. The graduate student was the best 
substitute we could arrange. 
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Chapter 1: This History, Professions, and their Ethics^ 



Old men forget: yet all shall be forgot 

But he'll remember with advantages 

What feats he did that day. 

— Shakespeare, Henry V 



1.1 Assumptions 



In the chapters following this one, I assume that the Software Engineering Code of Ethics 
and Professional Practice is both a code of ethics and a professional code. I also assume that 
what I describe is the process by which software engineering became a profession (more or less). 
Those assumptions are controversial. On some widely- accepted conceptions of "profession", 
software engineering still lacks crucial attributes of profession, such as licensure or workplace 
autonomy; and on some widely- accepted conceptions of ethics, the content, form, or origin of the 
Code rules out its being "ethics".^ Yet the story told here is not (primarily) about licensure, 
autonon^^, or the lite but about a code of ethics. To tdl that as the story of an occupation 
becoming a profession (a story of "professionalization"), I must errqioy v\tot are (still) 
controversial conceptions of ethics and profession To admit controversy is, however, not to 
admit that these conceptions are ad hoc or without impressive defense. The evidence that they 
are not ad hoc, like their defense, is to be found in part in what follows— insofar as the story I 
tell relies on these conceptions and seems the better for doing so— but primarily in what I have 
written elsewhere.^ This chapter is not the place to defend th^ conceptions; it is only the place 
to explain them in enough detail to assure that readers may read on without feeling lost either 
because they do not understand the conceptions at all or because they do not understand them 
well enough to conclude, however tentatively, that "there must be sonrfing to them". 

1.2 Ethics as Special Standards 

"Ethics" has at least five senses in ordinary English. In one, it is a mere synoriym for 
ordinary morality, those universal standards of conduct that apply to moral agents sinply 
because they are moral agents. Etymology fully justifies this first sense. The root for "ethics" 
("ethos") is the Greek word for custom or characterjust as the root of "morality" ("mores") is the 
Latin word for it Etymologically, "ethics" and "morality" are twins (as are "ethic" and 
"morale"). In this first sense of "ethics", software engineers could not have a distinct code of 
ethics because no one can Since ethics is universal, it is the same for aU. This sense of ethics 
would rule out the very undertaking we are to study. It cannot be the sense of "ethics" that 
concerns us. 

In four other senses, "ethics" contrasts with "morality". In one, ethics is said to consist of 
those standards of conduct that moral agents should follow (what is sometimes also called 
"critical morality"); morality, in contrast is said to consist of those standards that moral agents 
actually follow ("positive morality"). "Morality" in this sense is very close to its root "mores"; it 
can be unethical (in our first sense of "ethics"). "Morality" (in this sense) has a plural; each 
society or group can have its own moral code, indeed, even each individual can have her own. 
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There can be as many moralities as there are moral agents. You can have "your morality" (in 
which, say, abortion is wrong) and I can have "my morality" (in which it is not). But even so, 
ethics remains a standard common to everyone (or, at least, may be such a standard, depending 
on how one understands "critical morality"). The application of critical reason may (in time) 
yield a definite answer (say, that abortion is wrong, that it is not, or that it sometimes is and 
sometimes is not). 

"Ethics" sometimes contrasts with "morality" in another way. Morality then consists of 
those standards every moral agent should follow. Morality is a universal minimum, our standard 
of moral right and wrong. Ethics, in contrast, concerns moral good, whatever is beyond the moral 
minimum (for example, "how we should live our lives"). Ethics (in this sense) is whatever is left 
of morality (in our first— universal— sense, which includes both the right and the good) once we 
subtract morality (in this third- minimum right-only— sense). Since (as we shall see) 
professional ethics consists (in large part at least) of moral requirements, this cannot be the sense 
of "ethics" with which we are concerned here. 

There is, however, a connection between ethics in this sense and ethics in the sense that 
does concern us. What goes into a code of professional ethics should include some of ethics in 
this sense. Codes of professional ethics convert conduct that is morally good but optional for an 
ordinary person into a moral requirement for members of the profession in question. (I shall say 
a bit more about this in section 1.4.) 

The second (or "should") sense of ethics is closely related to a fourth, a field of 
philosophy ("philosophical ethics"). When philosophers offer a course in "ethics" ("applied 
ethics" as well as "moral theory"), its subject is various attempts to understand morality (all or 
part of morality in our first sense) as a rational undertaking. Philosophers do not teach morality 
(in our first, second, or third sense)— except perhaps by inadvertence. They also generally do not 
teach critical morality, though the attempt to understand morality as a rational undertaking 
should lead students to dismiss some parts of morality (in its second, descriptive, sense) as 
irrational or to feel more committed to morality (in its first or third sense) because they can now 
see the point of it. 

"Ethics" can be used in yet another sense, to refer to those special, morally- permissible 
standards of conduct governing members of a group simply because they are members of that 
group. In this sense, Hopi ethics are for Hopi and for no one else; business ethics, for people in 
business and for no one else; and legal ethics, for lawyers and for no one else. Ethics— in this 
sense— is relative even though morality is not. But ethics (in this sense) is not therefore mere 
mores (or ethos). Ethics must— by definition— be morally permissible. There can be no thieves' 
ethics or Nazi ethics, except with scare quotes around "ethics". 

This fifth sense of "ethics" is, I think, the one implicit in the claim that one profession's 
ethics differs from another (or, at least, the sense that yields the most interesting interpretation of 
that claim). So, for example, while a philosophy course in Computer Ethics might differ from a 
philosophy course in Engineering Ethics in many ways, most of those differences would be 
irrelevant here. What is relevant is that the special standards governing software engineers can 
differ from those governing other engineers and other "computing professionals". Without this 
special- standards sense of ethics, what now seems an ordinary undertaking— the writing of the 
Software Engineering Code of Ethics— would be mysterious: Why would software engineers 
devote years to writing their own code of ethics? Why did they take so much trouble with the 
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exact wording of so many provisions? Why did they claim their code differed from others? And 
why does their code seem so different from others? We must sometimes dismiss the reports of 
participants as self-deception, misunderstanding, cover-up, or exaggeration, but we are not 
entitled to do that without strong evidence, evidence that I have found neither in the documents I 
have studied, nor in what participants have told me, nor even in what I myself saw. We must 
therefore assume that the sense of "ethics" relevant here is this special- standards sense. 

Ethics in this sense resembles law insofar as both apply only to members of a specific 
group (rather than to everyone). Both are special standards. Ethics also resembles law insofar as 
both are standards to guide conduct (in prospect) and to judge it (in retrospect). Neither law nor 
ethics is a description of how people act (in the way a "scientific law" is a description). Both law 
and ethics tell us only how people should act. Having a standard is consistent with occasional 
violations. Indeed, we are unlikely to speak of standards, whether of law, ethics, or even skill, 
unless there are (or, at least, are likely to be) occasional violations. If, however, the violations 
become too numerous ("the rule rather than the exception"), the standard, whether legal or 
ethical, ceases to be an actual standard. It does not therefore die. The standard may live on as a 
"model" or "ideal". Ideal legal standards are standards that should be incorporated into legal 
practice. Ideal ethical standards are standards that members of the relevant group can recognize 
as what should (all else equal) be the actual standards of the group. The standards are merely 
ideal when they do not in fact govern practice. An ideal code of ethics is a possible or model 
code, a source of inspiration; an actual code of ethics, a living practice (as well as an ideal), a 
powerful claim on conscience. 

These similarities between law and ethics do not preclude a fundamental difference. Law 
applies to people whatever they want. It originates in a formal authority (answering the question 
"Who is to say?") and carries with it means of enforcement (of which police, courts, and criminal 
punishment are the most prominent). Ethics (in our fifth sense) applies to members of the 
relevant group only because of something they want (the benefits of tiie voluntary practice the 
standards in question create and maintain). The claim that ethical standards have on conscience 
depends on what the standards actually say. There is no "ethics authority" in the way there is 
legal authority. Ethics is a standard of conduct that everyone in the group wants everyone else to 
follow even if their following it would mean having to do the same. The members of the group in 
question, all of them, are the ethical equivalent of the law's formal authority. A code of ethics 
binds those it governs in the way an ordinary promise binds its maker, not in the way a formal 
contract does. 



1.3 Sociological Definitions of Profession 

Distinguishing that fifth sense of ethics from the other four suggests the question: 
What is professional ethics? How do the special standards of professions differ from 
other special standards (if they do)? The answer to such questions depends on what we 
mean by "profession". Unfortunately, "profession" resembles "ethics" in having several 
senses. "Profession" can, for example, be used as a mere synonym for "occupation"— an 
occupation being any typically full-time activity defined in part by an easily recognizable 
body of knowledge, skill, and judgment (a "discipline") by which one can (and people 
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typically do) earn a living. It is in this sense that we may, without irony, speak of 
someone being a "professional thief". "Profession" can, instead, be used for any 
occupation one may openly admit to or profess, that is, an honest occupation: "Plumbing 
is a profession; thieving is not." "Profession" can also be used for a special kind of honest 
occupation (for example, "knowledge workers"). 

There are at least two approaches to defining this special kind of honest occupation. One 
approach, what we may call "the sociological", has its origin in the social sciences. Its language 
tends to be statistical. The definition does not purport to state necessary or sufficient conditions 
for some occupation to be a profession but merely what is true of "most professions", "tiie most 
important professions", "the most developed professions", or the like. Every sociologist 
concerned with professions seems to have a list of professions the definition must capture. Law 
and medicine are always on the list; the clergy, often; and other professions, such as architecture, 
accounting, or teaching, sometimes.'^ 

We way distinguish three traditions in the sociology of professions (what we may call): 
the economic, the political, and the anthropological. Though iridividual sociologists often mix 
them in varying degrees, distinguishing them as "ideal types" here should help us to think about 
them more clearly, even in their less ideal (and more mixed) forms. What is wrong with all three 
ideal types, their failure to understand how central ethics (in our fifth sense) is to profession, 
remains even v\ten the types are mixed 

The economic tradition interprets professions as primarily a means of controlling marl^t 
forces for the benefit of the professionals themselves, that is, as a form of monopoly, guild, or 
labor urdon The economic tradition has two branches: Marxist and free marl^t Among recent 
sociologists in the Marxist tradition, the best is still Magali Sarfatti Larson {The Rise of 
Professionalism, 1977); among sociologists in the free-market tradition, Andrew Abbott (The 
System of Professions, 1988) is a good example. For sociologist in this tradition (whether 
Marxist or free market), it is the would-be members of a profession who, by acting together 
under favorable conditions, create their monopoly, more or less forcing (or tricking) society into 
going along. Successful professions have high income, workplace autonomy, control of who can 
join, and so on; less successful professions lack some or all of these powers (more or less). These 
signs of success, like the monopoly itself, may be embedded in law, but need not be. What 
matters for the economic tradition are market arrangements ("economic realities"), not (mere) 
law. The success in question may be independent of what participants in events sought. The 
economic tradition delights in discovering "the invisible hand" at work. 

For the political tradition, however, the law matters more. Often associated with Max 
Weber, the political tradition interprets profession as primarily a legal undertaking, a matter of 
(reasonably effective) laws that set standards of (advanced) education, require a license to 
practice, and impose discipline upon practitioners through formal (governmental) structures. To 
be a profession is to be an occupation bureaucratized in a certain way. For the political tradition, 
it is the society (the government) that creates professions out of occupations, and the society (the 
public) that benefits (whoever else may benefit as well). A recent work in this tradition is Robert 
Zussman's Mechanics of the Middle Class (1985). This tradition seems to have considerable 
influence among members of professions when they are trying to convince colleagues of the 
importance of supporting licensure: "We cannot be a profession if we are not licensed— as 
doctors and lawyers are." 

15 



The anthropological tradition, often associated with Emile Durkheim, interprets 
professions as primarily cultural facts, the natural expression of a certain social function under 
certain conditions. Neither the professionals nor society can have much to say about whether a 
certain occupation will be a profession. Professions are a function of special knowledge used in a 
certain way, a community created by a common occupation. Among recent sociologists, the best 
of those working in the anthropological tradition seems be to be Eliot Freidson (in, for example. 
Professionalism: The Third Logic, 2001). 

Distinguishing these three traditions helps make the point that the sociological approach 
has not yet yielded a single definition of profession and, more importantly, is not likely to. 
Sociology's way of developing a definition, that is, abstracting from a (short) list of clear cases 
whatever is common to most or all, is unlikely to yield a single definition— or, at least, is 
unlikely to until sociologists agree on a list of clear cases sufficiently long to produce a plausible 
definition. Today, only two professions appear on all sociological lists. That is much too few to 
derive a plausible definition— or even a "statistically" reliable one. Whatever the utility of a 
particular sociological definition for a particular line of social research, no such definition is 
likely to seem definitive to more than a minority of sociologists. Why sociologists continue to 
generate definitions in this way seems to be a question best left to the history (or sociology) of 
sociology. It need not concern us further. 

1.4 Professions and Codes 

The other approach to defining "profession" is philosophical. A philosophical definition 
attempts to state necessary and sufficient conditions for an occupation to count as a profession. 
While a philosophical definition may leave the status of a small number of would-be professions 
unsettled, it should at least be able to explain (in a satisfying way) why those would-be 
professions are neither clearly professions nor clearly not professions. Philosophical definitions 
are sensitive to counter-example in a way sociological definitions are not. Philosophers cannot 
use the standard defense of sociologists: "I said 'most', not 'all'." 

There are at least two kinds of philosophical definition. One, the Cartesian, answers the 
question, "What do / think a profession is?" It attempts to piece together in a coherent way the 
contents of one person's mind. There may be as many Cartesian conceptions of profession as 
there are people who ask themselves what they mean by "profession". The Cartesian method has 
no procedure for mediating between the definitions that individuals generate. Some of the 
definitions are startling.^ 

The conception of profession I shall be assuming here is not Cartesian but, as I lite to call 
it, Socratic. It answers the question, "What do we, practitioners and philosophers, ('really') think 
a profession is?" Such a conception must be worked out through a conversation. The members of 
various professions say what they mean by "profession". Philosophers, or other practitioners, test 
those definitions with counter-examples, with consideration of consequences adopting the 
definition would have, and in other ways typical of philosophical examination of definitions. 
Any problems discovered in this way are fixed by revising the definition. The definition is again 
tested. And so the process continues until everyone participating in the conversation is satisfied 
that no problems remain. It is this "critical conversation" (what the Greeks sometimes called 
"dialectic") that underwrites the claim that the resulting definition is "what we really think a 
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profession is". After many years of applying this method, I have reached the following 
definition: 

A profession is a number of individuals in the same occupation voluntarily 
organized to earn a living by openly serving a moral ideal in a morally- 
permissible way beyond what law, market morality, and public opinion 
would otherwise require. 

According to this definition, a profession is a group undertaking. There can be no 
profession of one. The group must share an occupation. An occupation is something more 
general than a job description. Indeed, the term is useful only where it gathers together a family 
of job descriptions under a single heading while still distinguishing that family from others. So, 
for example, a group consisting of accountants and engineers cannot form a profession, though 
accountants can form one profession and engineers another. There is little or no movement 
possible from one family to the other (without a new degree). The discipline required of one is 
too different from that required of the other. That is what makes them distinct occupations. 
Engineers, on the other hand, do form an occupation, even though some engineers work in large 
firms and some in small, some in government and some in business, some overseeing the 
construction of bridges and some designing microprocessors. Movement between one field of 
engineering and another, one sort of practice and another, is still sufficiently easy (and common) 
for engineering to count as a single occupation. Much the same is true of accounting (with 
respect to its fields).^ 

Since v\tot counts as a single occupation will depend on how much movement is possible 
between jobs of various descriptions, tbBB will always be a question whether some group 
consists of one occupation or two. For exanple, do pliysicians and surgeons forai one occupation 
or two? The answer to that question may depend on the reason it is asted For purposes of 
men±)eiship in the AMA, pliysicians and surgeons are (today) one occupation But for some 
purposes, say, the study of marriage patterns aoDss occupations, it might make more sense to 
treat them as two. 

To undertate to mate software engineering a profession is to answer yes (however 
tentatively) to the question, "Is software engineering a single occupation?" To answer that way 
is, however, not to rule out inp^itant differences between the jobs software engineers hold, only 
to assert that the similarities are (on balance) more inp)itait than the differences for tte 
purposes in view. Such an assertion of relative inp^itance may well be controversial— within the 
occupation as well as outside of it There is no way to resolve that controversy here. For us, v\tot 
is inpjitant is that the controversy does not prove that software engineering is not (yet) a 
profession or even distinguish software engineering from "the tme professions".' 

According to the definition of profession to be used here, the group in question (the 
would-be profession) must organize its occupation to work in a morally pemnssible way. Where 
there is no morally pemnssible way to cany on the occupation there can be no profession There 
can for exanple, be no profession of thieves or toiturere (since living ty theft or torture— in 
general, at least— is morally wrong). 

The would-be profession cannot however, rest content with avoiding acts that are 
morally wrong. A profession must set standards beyond v\tot law, martet (ordinary) morality, 
and public oprdon would otherwise require. That is, a professtion must set special standards. 
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otherwise the occupation would remain nothing more than an honest way to earn a living (as 
plumbing is, for example). These special standards will be ethical (in our fifth sense of "ethics"). 
They will be morally permissible standards that apply to all members of the group simply 
because they are members of that group. 

That professional ethics (in our first sense) applies to members of a profession simply 
because of that membership is no surprise. It is true by definition. What is surprising, I think, is 
that the standards in question (the profession's ethics) will be morally binding on every member 
of the profession simply because of that membership— and therefore ethical as well in both our 
first and second sense. Each profession is designed to serve a certain moral ideal, that is, to 
contribute to a state of affairs everyone (every rational person at her rational best) recognizes as 
good (that is, as what she wants to be). So, physicians have organized to cure the sick, comfort 
the dying, and protect the healthy from disease; lawyers, to help people obtain justice within the 
law; accountants, to represent financial information in ways both useful and accurate; and so on. 

These moral ideals must be pursued openly; that is, physicians must declare themselves 
to be physicians, lawyers must declare themselves to be lawyers, accountants must declare 
themselves to be accountants, and so on. The members of a (would-be) profession must declare 
themselves to be members of that profession in order to earn their living by that profession. 
They cannot be hired as such-and-such (say, a psychologist) unless they let people know that 
they are such-and-such. If their profession has a good reputation for what it does, their 
declaration of membership will aid them in earning a living. People will seek their help. If, 
however, their profession has a bad reputation, their declaration of membership will be a 
disadvantage ("I am a phrenologist"). People will shun their help. In general, if the members of 
an occupation are free to declare themselves or not, they will declare themselves only if the 
declaration benefits them overall (that is, serves at least one purpose of their own at what seems a 
reasonable cost). 

Where members of a profession declare their membership voluntarily, their way of 
pursuing the profession's moral ideal will be a moral obligation. They will, that is, have entered 
a voluntary, morally permissible cooperative practice (by declaring their membership in the 
profession— 'T am an engineer"). If hired (in part) because of that declaration, they will be in 
position to have the benefits of the practice, employment as a member of that profession, because 
the employer sought a so-and-so and they declared themselves to be one. They will also be in 
position to take advantage of the practice by doing less than the standards of the practice require, 
even though the expectation that they would do what the standards require (because they 
declared the appropriate profession) is part of what won them employment. If cheating consists 
in violating the rules of a voluntary, morally permissible cooperative practice, then every 
member of a profession is in a position to cheat. Since, all else equal, cheating is morally wrong, 
every member of a profession has a moral obligation, all else equal, to do as the special standards 
of the profession require. "Professionalism" is (strictly speaking) simply acting as the standards 
of the (relevant) profession require. To be a "professional" (or "a real pro") is to be a member (in 
good standing) of the profession— or (by analogy) to act as if one were (that is, to act in the way 
the relevant standards require). 

Like a promise, a profession's ethics— the special standards of the profession— impose 
moral obligations. Professional standards may, and generally do, vary from profession to 
profession. They are, at least in part, a function of opinion within the profession. Since opinions 
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vary, it is possible to have several professions sharing a single occupation, one profession 
distinguished from another only by its distinctive professional standards (arising from 
differences of opinion concerning important matters of practice). This is not a mere possibility. 
Professional standards, including somewhat different moral ideals, seem to be all that make 
physicians (MD's) one profession of medical healer and osteopaths (OD's) another. 

The special standards of a profession generally appear in a range of documents, including 
standards of admission, practice, and discipline. A code of ethics is, however, a central feature of 
a profession, a statement of the most general standards of practice. So, for example, in the United 
States, publication of a formal code of ethics is the signal that an occupation has organized itself 
as a profession. A profession is organized insofar as these special standards are realized in the 
practice of its members, in what they do and how they evaluate one another. 

Since formal codes of ethics were almost unknown outside English-speaking countries 
until well after the Second World War, some may object that this definition of profession is too 
"Anglo- centric".^ I have two (conpatilie) answers to this otgection The first is the professions 
have a history much as does the steam engine or parliamentary democracy— and, lite the steam 
engine and parliamentary democracy, much of that history seems to have occurred in English- 
speaking countries. For a time, the industrial revolution and parliamentary democracy were 
"Anglo-centric". Why, then, not professions too? Second, niy point about codes of ethics 
concerned formal codes. In many countries lacking such a code, technical standards may 
incorporate the same standards a code of ethics would in England, Australia, or the United States 
(though implicit in details rather than explicit in the more general terms characteristic of a code 
of ethics). The code of ethics may, in this sense, be both in writing and still "unwritten". Whether 
the technical standards of a given country in fact serve as a code of ethics will depend on the 
attitude that members of the (candidate) profession generally take toward those standards 
(assuming the standards to be morally permissible). If they regard them as extemal impositions, 
they count as law, not as an (unwritten) code of ethics. If, however, they regard them as 
standards they want everyone else in the profession to follow even if that would mean having to 
do the same, the standards do constitute a code of ethics (even if an unusually detailed one and 
even if enacted as law). 

An occupation's status as a profession is (more or less) independent of license, state- 
imposed monopoly, or other special legal intervention. Even a country with licensed attorneys 
may have no profession of law (just as the United States has licensed plumbers but no profession 
of plumbing). Indeed, professions should maintain a certain independence of law. While 
professions often commit themselves to obey the law, the commitment must be contingent. 
Insofar as the laws of a particular country are unjust (or otherwise fall below the moral 
minimum), any provision of a professional code purporting to bind members of the profession to 
obey the law (whatever the law says) would be void in that respect (just as a promise to do what 
morality forbids is void).^ 

1.5 Learning about professional ethics from history 

To deserve to go down in history is a good thing, but actually to go down in it may not 
be. In common speech, "You're history" is bad news, the information that the person addressed 
is about to die— involuntarily and long before her biological time. Generally, to write history is 

19 



tD write about the dead; the living belong to journalism and the social sciences. That was, 
however, not always so. When Thucydides wrote The Peloponnesian War, he wrote about events 
in which he had taken part. Even Herodotus, the "father of history", wrote his great work, 
Persian Wars, about events within living memory. It is with these Greeks in mind that I have 
written this case study. Though the story I tell is not about the collision of great armies or 
economic systems, events deciding the future of nations, it is nonetheless about a crisis in an 
important human institution (software engineering), a crisis within living memory. It is the story 
of how software engineering became a profession (in our preferred sense)— a story, not a 
sociological study, yet a story having significance for the sociology of professions— and for 
professional ethics. 

One way to read this book is as an investigation of how well the sociological approach to 
profession fits what we know of software engineering. For me, what is striking is how pooriy 
sociology's three ideal types (or any mixture of them) fits the story I tell. My characters are not 
(primarily) concerned with the conquest of markets, raising their income, or protecting 
themselves from competition; nor is there reason to believe that an unseen hand guided them to 
act as if they were so concerned. They were already doing well in the market— and expecting to 
do better. Though governmental intervention in the market, especially licensing, does have an 
important part in the story, its part is extrinsic, often threatening the movement toward 
profession. And, like most histories, mine is not (primarily) about cultural forces achieving the 
inevitable, but about contingent events, the interplay of personalities, and the place of words, 
organizations, and actions in human achievement. Of course, just as one cold day does not make 
a winter, so the failure of the sociological approach to fit one profession does not constitute a 
refutation. It does, however, constitute evidence against any theory of profession relying on one 
or more of sociology's three traditions. Sociological theories of profession should fit the 
professions they claim to explain. My story is a challenge to the sociology of professions as so 
far developed. 

That challenge would not be important if we had many studies like this one, and most of 
the others pointed in the opposite direction. In fact, we have no others. Few (if any) professions 
have an archive for the writing of a code of ethics to match that saved for software engineering. 
The absence of such archives may explain— in part at least— why, so far, historians have paid so 
little attention to professional codes. It is hard to write history without documents. Another part 
of the explanation may be that historians of professions, lacking any alternative, have followed 
sociology in emphasizing other features associated with professions, features easier to document 
than writing a code. Nonetheless, the closest to a book- length study of a code of professional 
ethics before mine seems to be a collection of studies. The American Medical Revolution, 
describing the entire (fifty-year) career of the first code of ethics of the American Medical 
Association. That collection draws much the same conclusion I do. Its leading editor, Robert 
Baker, also uses recent work in the philosophy of professions to sharpen the questions his 
historians ask the records they have.^° Our books seem to stand at the beginning of a new line of 
research.'' 

When I started this book, I thought of it as sociology (or journalism) rather lite Kidder^ s 
The Soul of a New Machine (a classic study of engineers designing, building, and testing an early 
computer) } ^ What made this book history rather than sociology, insofar as it is one rather than 
the other, is the evidence on v\Mch I came to rely. Much of the activity Kidder observed 
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consisted of people working with certain machines, conversations between those people, and so 
on. Most of what I observed were emails. Kidder augmented his observations with interviews, 
mostly interviews carried out while the people worked. Although I too interviewed participants, I 
interviewed them several years after the work I studied had ended. I did not, until then, have a 
grant to pay the expenses of interviewing. I could not even make a good case for such a grant 
until what I wished to study, the writing of an important code, had indeed produced a code likely 
to be important. 

I therefore had documents of a sort Kidder did not, hundreds of emails. I did not have to 
depend on notes I had taken at the time. I had the events themselves, the emails (or, at least, 
printouts of them), piled a foot high on my desk. That was an advantage. I also had interviews of 
a sort Kidder did not, interviews conducted several years after the events they were to help 
reconstruct. That proved a disadvantage. I was often in a position to check my interviewee's 
memory against emails (and other documents). I soon realized that the emails were a much more 
complete and accurate record than anyone's memory, indeed, than all of the memories put 
together. I could not rely on interviews in the way Kidder had. 

The Greeks wrote history about events within living memory (at least in part) because 
they lacked the archives that would have allowed them to write much about earlier events. For 
them, where memory, and the few surviving documents, ran out, history also ran out, and legend, 
myth, and fable (the playground of poets) began. Perhaps their memory was better than ours, or 
the events they studied, being more central to their lives, made a deeper impression, or perhaps 
much the Greek historians tell us did not happen— or did not happen in anything like the way 
they recount. I do not know. What I do know is that I have been deeply shaken by how much my 
interviewees forgot or misremembered. (They could report that they had never been reimbursed 
for travel when their own files showed they had; they could recall an important event that 
occurred in 1995 as occurring two years before; and so on.) I soon learned to bring a timeline to 
interviews (to prompt their memory and mine). Even so, I came to think that interviews can tell 
us much about what people are, what they think, and what they are doing, much less about what 
they were, thought, and did, even a few years before. 

Though I first noticed this failure of memory in others, I soon noticed it in myself as well. 
Not only did I sometimes forget events indifferent or even unpleasant to recall, but some I was 
happy to recover as documents proved me better than I supposed. Whatever the law of memory, 
it is not simply self-interest or pleasure (the "advantage" Shakespeare alleges at the head of this 
chapter) .There is no mechanical way to recover memory; indeed, often no safe way even to 
distinguish between true memory and false— apart from looking for harder evidence. Memory, 
even of recent events, is as much phantom as ghost. I have occasionally used interviews to fill 
gaps in the record, especially when two or more interviewees agreed on what happened, but I 
have preferred to use interviews to help me understand the documents. What memory seems to 
preserve best is the feel of things. 

To write about the living is always to risk hurting someone's feelings and, these days at 
least, to risk a suit for libel as well. To write, as I have, about people most of whom are still in 
good enough health to care what I write, literate enough to read it, and sufficiently lacking in 
diffidence to challenge me any time they think I have gotten something wrong, may seem even 
more risky. Y et, the risks here are, I am happy to say, much lower than in most studies. 
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Apollo 13 was an unusual success among movies. It lacked violence, sex, and even a 
villain. Its commercial appeal seems to have rested on nothing more than watching three moon- 
orbiting engineers, each imperfect enough to be likeable, successfully solve a complex practical 
problem (with the help of other engineers back on Earth). This book resembles Apollo 13 in 
lacking violence, sex, and villains. Those looking for scandal will be disappointed. This is a story 
of intelligent people successfully solving a complex practical problem. Part of the dramatic 
interest is watching good people trying to do good things. There are many small failures of 
knowledge, skill, and judgment, something to be expected in any human undertaking— and, 
something rare, a great failure just avoided. Much of the rest of the dramatic interest is in the 
conflict of ideas. Many of the disagreements between my characters are about what a code of 
ethics is, how it should be written, and what it should contain. We can see how theories of 
profession affect practice— and how practice can support some theories and raise doubts about 
others. 
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^ I have, please note, chosen two occupations where licensure is optional (for most 
purposes). When licensure is mandatory, as in law or medicine, we are liMy to suppose the 
license, not the discipline, creates the boundary. 

^ For those v\to think I should tate a firmer position on v\teher software engineers form a 

profession, I can think of no belter response than to quote David Hume, D ialogues Concerning 
Natural Religion, Part XII: "there is a species of controversy which, from the very nature of 
language and of human ideas, is involved in perpetual ambiguity, and can never, by any 
precaution or any definitions, be able to reach reasonable certainty or precision. These are the 
controversies concerning the degree of any quality or circumstance. Men may argue to all 
eternity whether Hannibal be a great, or a very great man... " 

^ I say "almost" because there were certainly some codes of ethics outside the English- 

speaking world before the Second World War. For exarrqie, the J^Miese Society of Civil 
Engineers adopted its first code of ethics in 1938 ("Beliefs and Principles of Practice for Civil 
Engineers"). Perh^:s if we looted, we would find marry more such exarrqies. 

^ I should lite to thank Seurnas Miller for questioning nie until I saw the need to rnate this 

point The point is, I tate it consistent with that made in Eugene Schlossberger, 'Technology 
and Civil Disobedience: Why Engineers Have a Special Duty to Obey the Law", Science and 
Engineering Ethics 1 Qune 1995): 163-168. While I doubt that engineers have the special duty 
that Schlossberger argues for, my point now is simply that its existence is independent of the 
claim I am making here. Engineers might both have that special duty and still have a reason to 
violate it if the laws are unjust enough. 

'° Roberts. Bateretal, The American Medical Ethics Revolution: How theAMA's Code of 
Ethics has Transformed Physicians Relationships to Patients, Professionals, and Societ]/ Qohns 
Hopkins University Press: Baltimore, 1999). For more about development of medical codes 
generally, see: Robert Baker, Dorothy Porter, and Roy Porter, editors, The Codification of 
Medical Morality, Vol. I (Kluwer Academic Press: Dordrecht 1993), which covers the period 
before the writing of the AMA code, emphasizing developments in England in the eighteenth 
century; and Robert Baker, editor, The Codification of Medical Morality, Vol. II (Kluwer 
Academic Press: Dordrecht 1995, covering the nineteenth (and early twentieth) century, with an 
emphasis on the United States. 

'' It is surprising how little has changed since Ivan Waddington, "The Development of 
Medical Ethics— A Sociological Analysis", Medical History 19 (January 1975): 36-51, observed 
in his opening paragraph: "It is a curious fact that despite the rapidly growing volume of 
literature on professions, little work has been done by sociologists on the development of 
professional ethics. This omission becomes doubly curious when one considers the central 
importance attributed to professional ethics in much of the literature on professions". 
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^^ Tracy Kidder, The Soul of a New Machine (Atlantic-Little, Brown: Boston, 1981). 
Perhaps it is worth pointing out that Kidder is a journalist. 
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Chapter 2: Before SEEPP, 1968-1994 



"In the beginning was the word. 
— Gospel of St. John 



2.1 NATO, DoD, and SEI 



The purpose of this book is to reconstruct from start to finish how SEEPP (the Software 
Engineering Ethics and Professional Practice Task Force) wrote, revised, and won approval for 
the Software Engineering Code of Ethics and Professional Practice. Studying SEEPP should give 
insight into how one profession formed, why it formed, and why it adopted a code of ethics. But, 
like all who try to tell a story, I face the question: where to start? Before there could be a SEEPP, 
there was an lEEE-CS ad hoc committee to establish software engineering as a profession. That 
ad hoc committee itself represented several decades of development, development that will help 
us understand what SEEPP was and what it was supposed to do— in a way the previous history 
of the universe does not. This chapter briefly describes that development. 

The term "software engineering" is one among several candidates for the name of what 
remains a new, relatively ill-defined occupation. Among the other candidates are "programmer", 
"software designer", "software developer", and "software architect". The earliest of these names 
seems to be "programmer". "Software engineer" seems to have come into currency after its use 
in the title of a 1968 conference sponsored by the Science Committee of the North Atlantic 
Treaty Organization (NATO).^ Tte term then expressed an aspration (as well as, as the 
oiganizeis intended, "a provocation").^ In 1968, writing conpjter programs ("software") was 
still largely a sideline, art, or individiialistic craft, most programmers working in their own way 
on relatively small programs. Few reported ("documented") much about their methods or about 
the stmcture or the guality of their software. Routine software, relatively small programs similar 
to eariier work, seemed to be satisfactory ("good enough" for the purpose intended). But too 
often novel programs, especially if large (involving, say, a thousand "man years"), arrived late, 
proved unreliable ("bug-ridden"), cost far more than originally budgeted, or failed to do much 
that was promised.^ The individualism of "traditional programming" did not fit the new scale. 
Because engineers generally work in teams on large systems, not as individuals, engineering was 
supposed to provide an alternative to programming practices then current "Software engineers" 
were to work in standard ways as other engineers do, teepang records in the way engineers 
typcally do. Software engineers were to be as good at predicting v\ten they would be done as 
engineers generally are, to be as good about staying within budget as engineers generally are, 
and to produce programs as useful and reliable as other engineering products are. Software 
engineering vvas to be an order of niagnitude better than rnere prograrnrning.* 

The organizers of the NATO conference, both developers and users of software, may 
have overestimated engineers. Almost every engineer has at least one story of a project that fell 
well behind schedule, was pooriy documented, went well over budget, or produced a product the 
performance of v\Mch fell far ^rt of expectations.^ What was inpjrtant, though, was not so 
much how good engineers actually are, as how bad programmers seemed to be. The organizers 
had a point no one at the NATO conference, or after, disagreed with even compared to 
engineers at their worst, the programmers of 1968 (however much they achieved) looked pretty 

25 



bad to each other and to those who increasingly asked them for large programs, programs too 
large for one or even a few programmers to write.^ 

The new name did not catch on quicMy. Almost two decades passed before it found an 
institutional home. But on January 1, 1985, under the authority of the Department of Defense, 
the Software Engineering Institute (SEI) began worlc in Pittsburgh The reason for the 
Departmenf s interest in software is easy to understand After World War II, the Department of 
Defense had sLovAy moved from buying stnqie hardware— tanks, radar, missiles, conpjting 
machines, and so on— to buying harchA^are dependent on software. More and more, v\tot gears, 
mechanical gauges, electrical switches, and similar devices had done was now being done by 
software. And much that hardware could not do at all or at a reasonable cost was also being 
done by software. Software was becoming an ever-larger part of v\tot the Department bought, 
and ever-more central to v\tot it did As the Department became more dependent on software, it 
also became more aware of how unreliabie the software was and how often the software was a 
cause of delays or cost-overruns affecting major we^xjns systems. 

In tte early 1980s, the Department of Defense decided to do something about its 
problems with software. It convened a shjdy group, a panel of experts lite others the Department 
organizes from time to time v\ten it has a problem that seems beyond its own experts. In 1983, 
the shjdy group recommended that the Department create "a federally funded research and 
development caiter" (FFRDC) for software. A FFRDC is a special corporation created by act of 
Congress. Each is dedicated to work with a unit of the US government Most such centers have 
an academic cormectiorL For exanqie, the California Institute of Technology has the Jet 
Propulsion Laboratory (JLP), a FFRDC that works for the National Aeronautical and Space 
Agency (NASA). The Massachusetts Institute of Technology has Lincoln Laboratories, a 
FFRDC worldng for the Defense Department 

The study group described the new center as a "software engineering institute". That 
description carried a message. The terai "software engineering" meant that the new entity was to 
be concerned with ^plications rather than with theory— with cost reliatality, timeliness of 
delivery, and other praHcal matters, not with corrpiter science generally. The term "institute" 
seems to have been chosen over 'laboratory" to rnate a similar point The new center was to 
develop standards rather than engage in experiments or develop end products (as labs do)— 
though it might do experiments or help devdop products along the way. The new center was to 
be more lite the National Institute of Standards and Technology (NIST)— v\Mch is not a 
FFRDC— than lite JPL or Lincoln Labs. 

The study group wanted the institutional connection for the new center to be chosen by 
corrpetition Because the businesses enable of managing such a center were litely to be 
government contractors v\to would benefit directiy from the choice of software standards, the 
shjdy group recommended that the conq^etition be limited to universities (though partnerships 
with business were allowed). Some twenty universities or groups of universities had for the 
center. Camegie-Mdlon University (CMU) won the conpetition So, after a few months of 
negotiation between the Department of Defense and CMU, SEI opened its doors on the edge of 
CMU's canpjs, giving the terai "software engineering" both a continuing official endorsement 
and an organization by v\Mch to convert a long-standing aspration into detailed standards for 
designing, writing, testing, and maintaining software. SEI was soon an inp^rtant force within 
programming, engaged not only in setting standards for software but in devdopng a curriculum 
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for educating future software engineers. SEI even helped to develop guidelines for a course on 
the ethics of software engineering/ 

2.2 Newjeisey, Licensing, and Fletcher Buckley 

By the eariy 1990s, hundreds of thousands of sofbA^are-idated woitens were called 
"software engineers", did something called "sofbA/are engineering", and had sophisticated 
enployeis willing to pay them to do it^ Some engineering societies had special interest groups 
devoted to software engineering. Marry universities had courses with "software engineering" in 
the title. There was even a two-volume Encyclopedia of Software Engineering about to go to 
press. Yet "software engineering" was not an ordinary engineering discipline. Few "software 
engineers" had a degree in engineering, that is, an undergraduate or graduate degree from an 
engineering program.^ Marry software engineers were graduates of a program in corrpjter 
science having a single course in "software engineering", a course typically taught ty someone 
with a degree in conpjter science rather than engineering. But some "software engineers" were 
self-taught, graduates of the school of hard knocks. Some worted to standards ariy engineer 
could be proud of, but marry fell far short of that Anyone, even a 1968-style programmer, could 
claim to be "a software engineer". Fiiqioyers, even colleagues, could not easily, or 
authoritatively, decide v\to was, and v\to was not, entitled to mate such a claim' ° 

Surveying the state of software engineering in the eariy 1990s, Fletcher Buckley (himself 
a software engineer at General Electric) drew the conclusion that it was time to mate software 
engineering a "profession". Others had similar ideas about the same time. For exanqie, on June 
27, 1991, the lower house of the New Jersey legislature passed Bill 4414 to license "software 
designers" (though some headlines said the Ml was only to "certify" them). The hall's sponsor 
defended the hall as a way "to protect consumers from unscrupulous developers."' ' Though the 
bill was initiated at the suggestion of a "computer consultant" with a certificate earned in 
England, it does not seem to have had the support of any professional society or of any large user 
of software.'^ Indeed, passage in the lower house seems to have generated considerable 
opposition from the large businesses that hired most of New Jersey' s software designers. The hall 
died in the upper house eariy in the 1992, but not without posing a question for software 
engineers. 

Here perii^:s is the place to explain some inpjrtant terais: license, certification, and 
registration A 'license" is a governmental permission to practice the licensed activity. 
Generally, the permission is granted upon application if certain qualifications are met (usually, 
education of a certain sort, certain experience, passing a test, and evidence of a good reputation, 
or some comhanation of these). In the US, Piofessional Fiigineers (PEs) are licensed in this 
sense. Only they can sign certain documents, perform certain services, or claim to be PEs. 
Licensure presupposes prohuMting all but the licensed from engaging in the activity in question. 

"Registration" is sometimes a synonym for licensing. But generally it indicates a less 
stringent form of regulation Those registered have the right to claim a certain title, though 
anyone can perform the corresponding function. So, for example, if software engineers were 
registered (in this sense) rather than licensed, only registered software engineers could use 
"software engineer" to describe themselves (or "software engineering" to describe what they do), 
but anyone could write software for any purpose, apply for jobs calling for "expertise in writing 
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software", and even advertise themselves as "software designers", "software developers", or 
"software architects". 

Generally, governments manage registration. "Certification" is registration performed by 
a no n- governmental body (such as the Institute for Certification of Computing Professionals). A 
no n- governmental body cannot control who does what work but it can (relying on trademark) 
control who can legally claim its certification. Anyone can claim to be a "computing 
professional", but only someone appropriately certified can claim (as well) to be a Certified 
Computing Professional.^^ 

The distinction between certification, registration, and licensing som^mes becomes 
muddled wbesa a government mates (private) certification a condition for registration or 
licensure. TMnk, for exanple, of Certified Public Accountants. In the U.S., state governments 
actually license CPAs, but a private group, the American Institute of Certified Public Accounts, 
still provides the test that an accountant must pass to be licensed as a CPA. The test is all that 
remains of certification 

Buckley lived and worl^d in New Jersey. For Buckley (as for marry v\to have thought 
about professions), licensing, registration, or certification seemed an inpjrtant mark of 
profession The brief fl^ over the licensing of programmers in New Jersey seems to have 
reminded Buckley of the unsettled state of his profession There was, first, the sinqie question of 
v\tot to call it Buckley thought of himself as a software engineer. But the New Jersey legislature 
had thought of the field (or part of it) as consisting of software designers— after some 
engineering societies complained about the use of the term "engineer" for a field they did not 
consider part of engineering. Some of those who spoke out against licensing described 
themselves as "artists", a description that "designer" seemed to authorize; some who spoke out 
against licensing described themselves as ordinary business people, a description that 
"developer" might seem to authorize.'* For Buckley, v\tot was missing from the appml to art or 
business was the idea that those who created soflw^, especially conqiex software upon v\Mch 
life, health, or property depends, should be held to a higher (a more demanding) standard than 
artists and business people are. It was this higher standard that was central to Buckley's call to 
mate software engineering a profession For him, making software engineering a profession was 
not a way to raise the social stahjs of programmers. In the US, people called "engineers" do not 
generally have higher stahJS than people called "designers", "developers", or even "architects". 
Indeed, if ar^lMng, the reverse is tme. The point of calling the new profession "engineering" and 
niaking it a fidd of that prof ession vvas to connect the new field to engineering' s vvay of carrying 
on worlc, a way that engineers generally believe deserves respect (v\tether it gets it or not). The 
thinking behirri Buckley' s call to mate software engineering a profession seems close to that of 
NATO' s more than two decades before. 

Though Buckley may not have been the first to conclude that it was time for software 
engineering to become a profession he was especially well placed to do something about it He 
had been trained as an engineer (He had a B.S. from West Point and a M.S. in Electrical 
Engineering from Stanford) He had had a long and distinguished association with the Institute of 
Electrical and Electronic Engineers (IEEE), serving from 1979 through 1990 as a member of the 
IEEE Standards Board (and of marry of the Board's standing committees). He had an equally 
long and distinguished association with the IEEE's Conpjter Society (lEEE-CS), serving as 
Chair of the Software Quality Assurance Plans Standards Worldng Group from 1976 through 
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1994 and as Chair of the Software Engineering Standards Committee from 1981 through 1983. 
In 1984, he became the Computer Society's first Vice President for Standards Activities. He had 
also served as a member of the lEEE-CS Board of Governors (1984-1986), initiated five IEEE 
software engineering standards seminars, and received several IEEE awards.^^ Buckley was a 
software engineer^ s software engineer. 

2.3 Buckley Proposes 

Qn April 15, 1993, Buckley began circulating a draft motion "to establisli software 
engineering as a profession" along with a long justificatiorL Among the venues he chose for 
publicity was the electronic Forum for Academic Software Engineering (EASE)— a long email 
regulariy sent to a list. The May 9 issue contained a letter that began "Dear Educator" and stated 
that the "following motion or some slightly altered version of it will be discussed in several 
meetings at ICSE (International Conference on Software Engineering) May 18-21, 1993 [in 
Baltimore]." The letter also indicted that its author ("we") "will be attending many of these 
meetings and will have a chance to present information about the motion" and that "there is a 
good chance that it will ultimately be considered by the lEEE-CS Board of Governors [which 
was to meet in Baltimore at the same time]." (Since Buckley had just been elected to his second 
term on the Board of Governors, he could be pretty sure of that "chance" to present the motion.) 
The letter concluded with an invitation to share "your thoughts" on three subjects: 

1. Defining Software Engineering and Software Engineering Ethics. 

Do you think this is possible at this point? Do you consider these definitions exist 
already (for example, in the SEI materials)? 

2. Accrediting Software Engineering programs at universities 

a. Is the Software Engineering curriculum mature enough for accreditation? 

b. Are the universities and professional societies prepared to undertake 
accreditation in Software Engineering? 

c. What would be the relationship between existing ACM/IEEE-CS 
accreditation process for Computer Science, the existing ABET 
accreditation process for Computer Engineering and the proposed ABET 
Software Engineering accreditation? Can the field and the universities 
support these subdivisions? 

3. Encouraging the states to establish software engineering as a registered engineering 
field 

Are we ready for this? What would be the impact on your program? 

Preceding the letter was a disclaimer from Laurie and John Werth, Vice Chairs for Education of 
the IEEE Technical Council on Software Engineering (TCSE): 

We have received a couple of replies to our long memo that indicate that the reader 
believes that Laurie or I authored the motion. In fact the motion is from Eletcher Buckley, 
a person from outside the ACM Ed Board, the lEEE-CS Educational Activities Board, 
the SEI or the executive committee of TCSE. In short it is an independent effort, but one 
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with enough steam behind it that the education community needs to think about its 
response. Let us have your thoughts and your references.^^ 

Buckley used the next issue of FASE {May 18) to announce "the motion is scheduled to be 
presented for ^Dproval to the IEEE CS BoG on Friday, 21 May 1993". Buckley also invited 
further comments and indicated that he would be making the rourids of the lEEE-CS boards and 
committees hopng to "gain insight". 

Qn Friday, May 21, Buckley moved "that the IEEE Conpjter Society Board of 
Governors ^Dpoint an ad hoc committee to initiate the actions to establish software engineering 
as a profession" The motion indicated that the work of the committee should include: 

a Deteraiining, in coordination with the Standards Activities Board, ^Dpropriate 
definitions and estatiishing those definitions as ^proved standards in accordance with 
IEEE Standards Board policies and procedures. 

b. Determining, in coordination with the Educational Activities Board (FAB), the body of 
knov\dedge required for a four-year undergraduate curriculum for a Bachelor of Science 
in Software Engineering and establishing this as an ^proved curriculum at the 
Accreditation Board for Engineering Technology (ABET). 

c. Deteraiining, in coordination with the Membership Activities Board (MAB), a set of 
software engineering ethics. 

d Encouraging, in coordination with the MAB and the FAB, states to establish software 
engineering as a registered engineering field consistent with currert practices in dvil and 
electrical engineering. Men±)ers on the committee shall be ^Dpointed ty the chair of the 
ad hoc committee. Membership on the committee shall be open to all interested parties 
including non-members of the Board of Governors, the Corrpjter Society, and the IEEE. 
The committee is authorized to initiate its work immediately.' ' 

Buckley' s motion was bound to be controversial for at least four reasons: 

First, according to paragr^ii (b), software engineering is to be a subdivision of 
engineering (shictiy so called), that is, defined ty an ABET-accredited baccalaureate program 
Though Buckley was himself a long-time member of the Association for Conpjting IVbchinery 
(ACM), he was here proposing something the ACM might oppose. In 1993, software engineers 
(unlite corrpjter engineers) generally got their degree in software engineering, if ariy, from a 
conpjter science department Most corrprter science departments were separate from electrical 
engineering (and conpjter engineering) departments. Indeed, marry were in the college of arts 
and sciences (with the other sciences), not in the engineering school. Conpjter science had its 
own system for accrediting programs, the Conpjter Science Accreditation Board (CSAB), still 
independent of ABET (though cooperating ever more closely with it). To mate software 
engineering a "profession" seemed liMy to move the education of software engineers from the 
conpjter science department (a science program) to the engineering school (a professional 
program).'^ 
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Second, according to paragraph (c), the new profession, even though a new engineering 
profession, was to have its own code of ethics. For Buckley, apparently, having a code of ethics 
is central to being a profession. That was a proposition with which most engineers might agree. 
But Buckley seemed to assume that the new profession's code would not be the IEEE's or 
ACM's but something distinct from both. Since both the ACM and the IEEE had recently 
adopted new codes of ethics, codes with which (presumably) they were still happy, Buckley's 
assumption that yet another code of ethics was needed seemed to define software engineering as 
a new profession distinct from both computer science and other parts of engineering, inviting 
opposition from within IEEE as well as from ACM. 

Third, according to the first sentence of paragraph (d), the ad hoc committee was to do all 
within its power to ensure that software engineers must be "registered". Neither the IEEE nor the 
ACM had the power to register or license engineers. Their only power was (and remains) to 
encourage (American) states (the standard jurisdiction for registering or licensing engineers in 
the US) to register or license software engineers. According to Buckley's motion, the registration 
was to be done more or less as it was done for "civil and electrical" engineers. This reference to 
registration of engineers may be intended to assure readers that the sort of licensing in question is 
not the sort typical of barbers, carpenters, and other no n- professionals. But the reference may 
have had another objective. Of the major divisions in engineering, the electricals had the second 
lowest rate of registration in 1993 (9%)— with chemicals coming in right behind (8%). Civil 
engineers had the highest rate of registration (44%).^^ Buckley's mention of electrical 
engineering in this context was not surprising. Software engineering is closely related to 
electrical engineering. But the reference to civil engineering seems to suggest that the registration 
should be made as integral to software engineering's status as a profession as it was to civil 
engineering's (a necessity for any civil engineer in a responsible position on an important 
project). Most important, this step in the process of making software engineering a profession 
(encouraging the states to begin registering software engineers) was to be taken immediately— 
before the ad hoc committee had reported anything back concerning curriculum or code of 
ethics. The lEEE-CS Board of Governors was, in effect, asked to approve registration before it 
even knew whether registration was practical. 

Asking the lEEE-CS Board of Governors to approve paragraph (d) might also mean 
preempting a discussion already in progress. Immediately following Buckley's memo in EASE 
no. 13 (May 18) was a communication on the subject "Licensing and Certification meeting". It 
simply quoted in full the following (undated) email: 

LAST WEEK I SENT OUT AN ANNOUNCEMENT OE A EORMAL PROPOSAL 
EOR A STANDARD TO LICENSE SOFTWARE PROFESSIONALS. THIS 
PROPOSAL WILL BE PRESENTED TO THE IEEE BOARD OF GOV.S AT THE 
ICSE [International Conference on Software Engineering] CONFERENCE IN 
BALTIMORE. AN INFORMAL LUNCH ON FRIDAY 21 MAY AT 12.15 IS 
PLANNED TO DISCUSS LICENSING AND CERTIFICATION. THE LUNCH IS NOT 
SPONSORED BY ICSE, BUT BY SOME PEOPLE INTERESTED IN LICENSING & 
CERTIFIC ATION. 
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WE PLAN TO MEET AT THE NICKEL CITY GRILL (201 EAST PRATT STREET, 
BALTIMORE 21202, 410 752 0900) 

I WILL REPORT TO THE LIST ON THIS AND OTHER DISCUSSIONS ABOUT 
LICENSING AND CERTIFICATION. 

DON GOTTERBARN 

Though this memo says that a licensing proposal would be put before the "IEEE Board of Gov.s 
at the ICSE", what must have been intended (and understood) was that such a proposal would be 
going before the lEEE-CS Board of Governors. (The IEEE's governing board, the Board of 
Directors, was not meeting at the ICSE.) In fact, no such motion did go before the Board of 
Governors (except in the subsidiary form of Buckley's item d). Gotterbam's memo shows 
independent interest in licensing and— with its invitation to a lunchtime meeting— more 
opposition to licensing than to other elements of "professionalization". The lEEE-CS Board of 
Governors had good reason to move cautiously on licensing.^" 

Last, and almost as controvensial as the first sentence of (d), are the three other sentences 
of (d). These, concerning inplementation, have no connection with the first sentence— and, 
indeed, should have been a separate paragr^±L They represent the only change BucMey made 
after beginning to circulate his draft on April 15. According to the three sentences, the ad hoc 
committee on making software a profession is to be at once wide-open in potential membership 
and (for an inpjrtant committee) unusually sutgect to "stacking". The motion allows ariyone in 
the world to serve on the committee ("ariy non-member of the. . .IEEE"). But the chair of the ad 
hoc committee is to choose the men±)ers and may choose v\tom she wishes without consulting 
ariyone else. 

2.4 A substitute motion approved 

The details of Buckley's motion are interesting now only in showing the state of his 
thinking at the time. By a vote of 15-2-5 (15 yes's, 2 no's, and 5 abstain' s), the Board of 
Governors quickly substituted another motion for it After one further amendment (the addition 
to paragraph 4 of everything following the hracteted clarification I have added), the following 
motion was put to a vote: 

That the Board of Governors of the IEEE Conpjter Society establish an ad hoc 
committee, ^Dpointed by the president, to serve as a steering group for action, planning, 
evaluation, and coordination related to establishing software engineering as a profession, 
sutgect to: 

1. The ad hoc committee (the steering group) will be conpjsed of wdl-respected 
individuals (such as IEEE Fellows from the Conpjter Society's software 
engineering community, others of similar standing, and representatives of 
involved Corrprter Society units) with a balance of industry, research, and 
academic backgrounds. 
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2. The committee will coordinate on this issue with the various Computer Society 
boards and committees, other professional societies, and other communities. 

3. The committee will establish and appoint task forces and working groups as 
necessary to accomplish the committee's work, with membership open to 
interested parties including non-members of the Computer Society and the IEEE. 

4. The various proposals presently submitted are referred to the committee for 
appropriate action to advance software engineering as a profession. [The 
committee shall] Consider and document the issues associated with software 
engineering as a profession, including, but not limited to: 

The factors involved in, and the value thereof, of establishing software 
engineering as an approved program including the associated accreditation 
issues. 

The factors involved in, and value thereof, of establishing a separate set of 
software engineering ethics. 

The factors involved in, and the value thereof, of establishing software 
engineering as a certified or registered field. 

5. The committee is charged to report on its initial plan and program at the time of 
the November 1993 Board of Governors meeting.^^ 

What are we to mate of this sutstitution? One thing is plain There was little resistance to 
Buckley's tag idea (creating a profession by defining a body of knov\dedge, an accredited 
ciraiculum, a code of ethics, licensing, or some comtanation of these). Most members of the 
Board voted for a committee to set in motion a process that could end in sofbA/are engineering 
becoming a profession in precisely the sense Buckley intended What the minutes of the meeting 
report is not different ways of understanding "professionalization" but different ideas of how to 
proceed 

The author of the substitution motion was Elliot Chikofsky. Chikofsky was another 
software engineer (as were an unusually large number of that year^ s Board of Governors).^ ^ He 
had a B.S. in Conpjter and Communications Science (1972) and an M.S. in Industrial and 
Operations Engineering (1978), both from the University of Michigan (UM). In the eariy 1980s, 
he had been the co-founder and vice-president (chief operating officer) of a UM spn-off, an 
eariy developer of conpjter-aided software engineering (CASE) technology. In 1993, he was 
director of research and technology for Index Technology Corporation (mater of Excderator 
products) and had just become Chair of the Technical Council on Software Engineering (TCSE, 
at the time, lEEE-CS's largest technical councU).^^ Within a few months, the new Encyclopedia 
of Software Engineering would describe Chikofsky as: 
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a developer, organizer, and evangelist of software engineering automation... [he] 
is known for his advocacy of reverse engineering and CASE technologies.. .a 
consultant on management issues regarding the application of software 
technology to solving business problems, as well as on information systems 
development methods, tools, and design techniques.^^ 

Qn May 18, Chik)fsky had chaiiBd a meeting of TCSE' s executive commitbee at which 
Buckley explained his motiorL Chik)fslcy had invited Buckley because he wanted to see how 
Buckley proposed to respond to what ChikDf sky thought was a deep split between conqxiter 
science aid engineering on the issue of making software engineering a profession While 
Chik)f sky agreed that sofbA/are engineering should be a profession, he did not favor tiying to 
mate it one if the attenpt would split the sofbA^are engineering community.^ ^ 

The executive committee had opened the May 18 meeting to anyone v\to was interested 
With between fifty and sixty people present in a relatively small room (assigned the executive 
committee with a membenship half that number), the atmosphere was electric. Though there were 
a number of questions to Buckley, the meeting soon turned into a series of exchanges between 
Buckley and Mary Shaw. Shaw was not an engineer. A professor in CMU' s Conqxiter Science 
Department, she had begun teaching there as soon as she received her B A. inMaftematicsfrom 
Rice University in 1971 (receiving a PhD. in Corrpiter Science from CMU a few years later). 
She was nonetheless very much a part of software engineering. She had published widely on 
"value-based software engineering" and taught software engineering at CMU. From 1984 to 
1987, she had served as chief scientist at SET. In 1990, she had published a well-received paper 
arguing that software engineering was not yet a "tme engineering discipline" and could not be 
until it had developed its "science" a good deal more. At the TCSE's May 18 executive 
committee meeting, she repeated her published arguments, making clear along the way that 
engineers and conqxiter scientists might not think alite about the status of software engineering 
as a profession or an engineering discipline. 

Chik)fsky soon concluded that he should not support Buckley's motion (as it would be 
presented to the Board of Governors on May 21) because it settled all the inpjrtant questions in 
a way liMy to exclude conpjter science departments from training software engineers. Settling 
those questions that way would probably create too much opposition from conpjter science 
faculty within lEEE-CS (not to mention opposition from the ACM) . Buckley' s motion would not 
pass tie Board —or, if it did pass, would still not achieve its otgective. Opposition would soon 
mate it a dead letter. Chitefsky therefore drafted a substitute in the three days between the 
TCSE meeting and the Board meeting. 

According to the substitute Chitefsky offered, the ad hoc committee would have a 
general mandate "related to establishing software engineering as a profession" (a mandate so 
general that few would otgect). For Chitefsky, v\tot mattered were the procedures (paragr^±is 
1-5). Apparently, other men±)ers of the Board thought otherwise. Chitefsky' s motion was soon 
aniendedty addition to paragraph 4 of v\totbecanie its final sentence and a list of "factors" that 
the ad hoc committee should consider. This amendment was relatively "friendly". Though 
Chitefsky did not mate it he did second it It passed 20-1-2. The main motion (as amended) 
then passed 18-1-4. 
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As passed, Chikofsky's motion accepted Buckley's conception of profession as including 
"approved standards", a curriculum, a code of ethics, and licensure (or "registration"), but 
rejected Buckley's attempt to determine how the categories would be filled in. The final motion 
allowed the ad hoc committee to fill in the categories as it saw fit, putting off some battles and 
perhaps avoiding others altogether. The committee might recommend a special accreditation 
procedure for software engineering programs, ABET accreditation, or none, might recommend 
establishing a separate code of ethics for software engineering or not, and might recommend 
licensure for software engineers or not. But, whatever the ad hoc committee recommended, its 
recommendations were likely to cany considerable weight. The membership of the committee 
assured that. The committee was to have members both individually "well- respected" and 
together representing the major constituencies of lEEE-CS, "industry, research, and academic". 
The committee was to be balanced enough and authoritative enough for its recommendations to 
have wide support, support on the computer- science side of the lEEE-CS as well as on the 
engineering side. 

2.5 The Steering Committee begins work 

Though the May 21 motion set a deadline of November 12 for completion of the ad hoc 
committee's work, work did not begin immediately. Finding just the right people to serve on the 
committee took longer than expected. Not until September did the committee "meet" for the first 
time. There were then only six members (including James Aylor who, as lEEE-CS President, 
was a member ex officio), but each member offered something the others did not. Buckley was 
one of the six, there no doubt to represent his own ideas. Two others, coming from SEI, would 
count as researchers. One, Mario Barbacci (chair), held a bachelor's degree from the University 
of Engineering (Lima, Peru, 1966) and a Ph.D. in computer science from CMU (1973). His 
specialty in software engineering was quality attributes and software architecture. The other 
researcher, Larry Druffel, was then in his seventh year as SEI Director. He had a BS in electrical 
engineering from the University of Illinois, an MSc in computer science from the University of 
London, and a Ph.D. in computer science from Vanderbilt.^^ Qf the remaining two, one, Winston 
Royce, was, lite Buckley, an engineer from indusby. Royce's technical woilc in sofbA/are 
engineering at TRW was inpjitant enough to earn lim a haogi^±y in the Encyclopedia of 
Software Engineering.^^ The last member of the steering committee was Stuart Zwebea an 
academic (professor. Department of Conpjterand Infonnation Science, Ohio State University). 

What explains tte stmcture of this committee? Royce provided industrial weight; Dniffd, 
research weight. Buckley seems to be there because he originated the motion Buckley would 
have been the obvious choice for the chair had Chik)f sky not actually made the substitute 
motion ultimately adopted While Chik)f sky was not yet on the committee, he had been asted to 
serve. With both on the committee, having the committee chaired by one of the other members 
would prevent any ntffling of feathers. Bartexi was a reasonable choice. Lite Buckley and 
Clitefsky, he favored establishing software engineering as a profession But, unlite Buckley, 
Bartaxi was not publicly committed He was then lEEE-CS Secretary; so, he could teep the 
other members of the Board' s Executive Commitbee infonned v\ten Aylor could not attend the 
ad hoc committee' s meetings.^ ^ 
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Zweben is more interesting. He was not there as an academic. Norm Schneidewind 
(professor, Naval Postgraduate School) would soon join the committee to fill that slot. Nor was 
Zweben there as software engineer (though he was one). Zweben, the only member of the 
committee without a degree in engineering, was there because he was ACM Vice President— and 
had volunteered. He had volunteered because the preceding month (August) the ACM Council, 
the ACM' s governing body, had adopted the following motion: 

Council endorses the establishment of a Commission on Software Engineering to address 
the question contained in Council backup. Item 3.7, Pages 3-4 of 7. If possible, this 
activity shall be done jointly with the IEEE Computer Society. The Executive Committee 
shall appoint (ACM's) members of the commission, provide it with a reasonable expense 
budget, and take other steps as may be necessary to assure that the commission may 
complete its work in timely fashion. 

Item 3.7 (dated July 15 and bearing Zweben' s initials) took the form of a background statement 
and a proposed action. The background statement observed in part: 

There are ongoing concerns about the persistent inability to construct software systems 
that are reliable, dependable, usable, on time, and within budget. These concerns are 
exacerbated by the widening reliance on computers and networks for conduct of all 
business and other human activities, and by the increasing role of software in supporting 
human activities of all kinds. The term "software engineering" is typically used to 
designate the board field of study and practice that addresses these concerns. Terms such 
as "software design" and "software architecture" also have been used for this purpose, to 
focus attention on important and fundamental questions that must be answered 
satisfactorily before good software can be built routinely .^° 

Item 3.7 went on to claim that the ACM had a long hisboiy of interest in "these concerns", that a 
large fraction of its members ("about 40%") were "professionally directly irwolved with sofbA^are 
development", and that almost everything about tte professionalization of sofbA/are engineering 
should be open for discussion: 

Terais such as "discipline" and "profession" have been used to characterize software 
engineering, and to argue for varying degrees of regulation for individuals in this field At 
the same time, strong otgections to these characterizations and to ariy regulatory efforts 
have been voiced There are strong disagreements about v\tether software engineering is 
propedy regarded as engineering, v\teher software engineering adequately covers all 
relevant aspects of design, v\tether software engineering should be separated from 
corrpjter science, and v\tether software engineering is mature enough to be called a 
discipline.... 

There is a strong need to clarify terminology, to identify both generally accepted and 
desirable standards of good software practice, and to further our alility to educate and 
train individuals to be con^Debent with software engineering and design^ ' 
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The only action Item 3.7 called for was "[chartering] a Commission on Software Engineering to 
provide a white paper that assesses the field of software engineering relative to the issues raised 
above." Then, for good measure, Item 3.7 listed eight specific questions that the commission was 
to address. Item 3.7 also suggested that the commission should include "leading people from 
software engineering, academia, industry, and government", should gather "information from 
other knowledgeable groups and from related published material", and should "cooperate with 
other organizations having an interest in similar questions". The commission was to complete 
work by April 30, 1994. In this way, the ACM Council made it possible to cooperate with the 
lEEE-CS as the ACM "assessed" making software engineering a profession. Clearly, the ACM 
was less committed than lEEE-CS to making software engineering a profession. The ACM 
wanted to study the question, not (as lEEE-CS) to take action. 

Well before tiie November 1993 deadline that the lEEE-CS Board of Governors had set 
for a report on the ad hoc committee's "initial plan and program", Barbacci and Aylor agreed 
"the magnitude of the task would require the coordinated activities of several task forces, with 
different assignments and schedules." They therefore transformed the ad hoc committee into a 
"steering committee" that would define a process and agenda for the working committees and 
task forces under it (a normal IEEE structure). This transformation was part of what seems to 
have been a relatively informal process. The committee never met in one place; it conducted 
business largely by email (then quite new). Only occasionally did a few members of the 
committee meet for informal discussion when chance brought them face- to- face. Only on 
November 8 did a majority of the committee (Aylor, Barbacci, Buckley, and Schneidewind) 
gather in one place (in Santa Clara, California) on the eve of the Board of Governors meeting 
there.^^ 

2.6 The Steering Commitbee' s Four Recommendations 

Qn November 12, 1993, the steering committee (often lefened to infonnally as "the blue 
ribbon commitbee") made four recommendations: The first was to adopt "a standard set of 
definitions". The chief concern here seems to have been the definition of "software engineering" 
itself. The commitbee suggested beginning with IEEE Standard 61012: 

Software Engineering: (1) The ^plication of a systematic, disciplined, quantifiable 
approach to the development opa:ation, and maintenance of software; that is, the 
ajplication of engineering to soflw^. (2) The study of ^Dproaches as in ( 1). 

The task of devdopng the necessary definitions for the worlc ahead was to be assigned to the 
Standards Activities Board of lEEE-CS (and ^Dpropriate subcommitbees). This recommendation 
was identical to (a) in Buckley' s original motion 

The steering committee' s second recommendation was "identification of a required body 
of knov\dedge and recommended practices". Recognizing that the knov\dedge of software 
engineering was evolving, the committee recommended that the task of identifying the body of 
knov\dedge be carried out primarily by "industry experts", those liMy to be most up to date. This 
recommendation was a departure from Buckley's original motion His recommendation (c) was 

37 



for the steering committee itself to identify the body of knowledge in cooperation with the lEEE- 
CS Educational Activities Board. Apparently, the steering committee came to believe that 
defining the body of knowledge was too big and technical an undertaking for it or a few 
academics to undertake. Nonetheless, as events were to show, the steering committee drastically 
underestimated the difficulty of defining the body of knowledge. 

The steering committee's third recommendation was "to study and customize, if 
necessary, existing codes [of ethics] already adopted by IEEE, ACM, registration boards, and 
other relevant organizations." The committee suggested that this task be assigned to the lEEE-CS 
Committee on Public Policy (COPP). This was another significant departure from Buckley's 
original motion. His paragraph (d) had anticipated that the Membership Activities Board (MAB) 
would work out a code of software engineering ethics. COPP now seemed the more appropriate 
body (though the steering committee did not explain its preference for COPP). 

The last of the steering committee's recommendations was that an "academic task force 
drawn from educational boards within the SEI, ACM, and IEEE Computer Society, and relevant 
affiliate societies," define curricula for (a) undergraduate, (b) graduate (MS), and (c) continuing 
education (for retraining and migration). ^^ The commitbee declined to get involved in the 
potential "turf war" betwrni corrpiter science and engineering about v\to "owned" the software 
engineering cuiricula: 

There is a debate as to v\tether Software Engineering is a pait of Conpjter Science or 
vice versa We should not be distracted by this debate from the goal of meeting the needs 
of industry. The education needed for conpetent software engineers could be acquired in 
different ways. For exanqie, we might idientify the need for a foundation on statistics 
[sic]; at a given school, the courses could be offered by Conpjter Science, Software 
Engineering, or other departments. The otgect is to seek agreement on the curricula that 
should be taught and not necessarily on v\Mch departments teach it ^ * 

The steering committee's handling of the curriculum question differs from Buckley's 
original motion in at least three inportant ways. First, the committee broadened the discussion to 
include graduate and continuing education. Buckley's paragr^Dh (c) had concerned only 
undergraduate education Second, the committee had broadmed those expiidtiy to be included in 
the development of curricula (adding SEI and ACM education boards). Buckley had mentioned 
only the lEEE-CS Educational Activities Board Third, the committee separated questions of 
curriculum from questions about the code of ethics. The separation meant that work on the code 
of ethics could proceed much more quickly and without the political infighting liMy to occur 
when the sutgect was v\to should teach wteL But that separation also ignored v\tot some 
thought the logical sequencing of activities: First, define the body of knov\dedge. Then set 
standards of practice, including a code of ethics. Only v\ten these were settied would it be 
possible to decide v\tot should be the curriculum and how accreditation should be done. The 
development of curricula and code of ethics were to proceed independentiy of defining the body 
of knov\dedge. 

The report s "Epnlog" indicated that the committee would tate up licensing, certification, 
and other "regulatory instmments" in "our next report". The commitiee' s next report (March 4, 
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1994) did not do that. Instead, it merely described progress on the four recommendations 
discussed above. The progress suggests substantial change in how the committee saw its work: 

1) Define the body of knowledge and recommended practice— we initiated a task force 
populated mostly with industry people, led by Patricia Douglas of IBM. 

2) Define a code of ethics— we initiated a task force co-chaired by Robert Melford (CS) 
and Don Gotterbam (ACM). 

3) Define the curricula— we have agreement from Doris Carver (CS) and John Werth 
(ACM) to co-chair the task force.^^ 

Concerning its first rBCommendation ("defining temis"), the commitbee now suggested (after 1-3) 
that "[this] is probably better done by the three task forces since they are the ones v\to wUl 
identify the terms that need to be in the 'glossary." The committee also helpfully suggested 
"various IEEE standards. . .might provide the bulk of the definitions, so there is not urgent need 
to have this as a separate 'task force' ."^ ^ In effect, the steering committee had given up this part 
of Buckley' s original plan (along with licensing). 

What had h^^:ened over the preceding six months to explain these changes in the way 
the committee saw its work? First, and perhaps least inportant, tte committee' s membership hsd 
changed The committee had added Elliot Chik)fsky and lost James Aylor (v\to had conqieted 
his terai as lEEE-CS president). While Laurel Kaledia had succeeded Aylor as president, she did 
not join the committee. Zweben remained on the committee and would soon become vice-chair 
(though only briefly). Second, and more inportant, the two presidents had worted out a way for 
the two sodelies to cooperate on establishing software engineering as a profession. The 
agreement, presented to tte lEEE-CS Board of Governors as a letter from lEEE-CS President 
Kaledato Bdl, stated: 

The members of the steering committee will include Mario v\to will continue as chair, a 
vice-chair (^Dpointed by you as president of the ACM), and six men±)ers, three appointed 
by each society by v\totever mechanism and for whatever terms the societies may 
choose. The steering committee may add additional men±)ers (such as the chairs of the 
task forces established by the steering commitiee) as ex officio, non-voting men±)ers of 
the steering committee. Mario may identify other details to be worked out, but these are 
the general guidelines underv\Mch we can get started^ ' 

The steering committee thus officially became a joint lEEE-CS/ACM committee. The chairing 
of two of the three tasks forces alreacfy reflected the joint nature of the new steering committee. 
The committee itself now had to reorganize to reflect that joint nature in the same way, 
becoming the Joint Commitbee for the Establishment of Software Engineering as a Professron 
Out of that reorganization would come SEEPP. 

Last, but pedi^DS equally inportant, the steering committee's re-defining of its task 
seemed to arise (in part at least) from increasing clarity about v\tot should, and could, be done, 
when, and how. We will see more such re-defining of tasks in succeeding ch^Dters. 
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Notes 

1. Gary A. Ford and James E. Tomayko, "Education and Curricula in Software 
Engineering", John J. Marciniak, Editor, Encyclopedia of Software Engineering, v. I (John Wiley 
& Sons: New York, 1994), p. 439. 

^ "The phrase 'software engineering' was deliberately chosen as being provocative, in 

inlying the need for software manufacture to be based on the types of theoretical foundations 
and practical disciplines, that are traditional in the established branches of engineering." Peter 
Naur and Brian Rcodel, editors. Software Engineering: Report on a conference sponsored by the 
NATO Science Committee, Garmisch, Germany, 7 to ii"" October 1968 (Scientific Affairs 
Division, NATO: Brussels 39, Belgium, January 1969), p. 13. 



^ "The basic problem is that certain classes of systems are placing demands on us which 

are beyond our c^shalities and our theories and methods of design and production at this time. 
There are maiiy areas v\tere there is no such thing as a crisis— sort routines, payroll applications, 
for exanqie. It is large systems that are encountering great difficulties. We ^uld not expect the 
production of such systems to be easy." JVA TO Conference, p. 16 (quoting K. Kolence). 



^ For a humorous statement of this view, consider the fifth of "Murphy's Technology 

Laws": If builders built the way programmers program, the first woodpecker that came along 
would destroy civilization. Compare Steven McConnell and Leonard Tripp, "Professional 
Software Engineering: Fact or Fiction", IEEE Software, November/December 1999: 13: 

The most common approach to software development today is code-and-fix 
programming— hacking. In this approach, a development team begins with a general idea 
of what they want to build. They might have a formal specification, but probably not. 
They use whatever combination of informal design, code, debug, and test methodologies 
suits them. Programmers write a little code and run it to see whether it works. If it doesn't 
work, they change it until it does. The code-and-fix approach is far from the state of the 
art in software development. It costs more, takes longer, and produces lower- quality 
software than other approaches; its main advantage is that it requires little technical or 
managerial training. 

Or, even more recently, Charles C. Mann, "Why Software is So Bad", Technology Review, 
July/August 2002: 33-38. 

^ See, for exanqie, Thomas O' Boyle, "Chilling Tale: GE Refrigerator Woes Illustrate the 

Hazards in Changing a Product— Firm Pushed Development of Corrpessor Too Fast, Failed to 
Test Adequately," Wall Street Journal, Monday, May 7, 1990, pp. 1 ff., for the story of a half 
billion dollar write-off having nothing to do with software. 
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^ There is more than one interpretation of this ^Dpearance possible. One view, more or less 
Marxist, is that rrianagerrientvvas following its usual p^teni of trying to tirai a skHled craft 
more easily controlled workforce in v\Mch "hand work" and "head work" are separate. See, for 
exanple, Philip Krafts study of "software worters" in the decade immediately following the 
NATO conference: Programmers and Managers: The Routinization of Computer Programming 
in the United States ( Springer- Verlag: New York, 1977). Another interpretation is that this is an 
attempt to raise the social status of programmers. Counted as "engineers", programmers will 
have more respect. A third interpretation, much closer to what participants actually said, is that 
software was not as good as it should be and that those responsible for it were looking for any 
way they could to improve it. 

' For a hat more on these guidelines, and their eventual fate, see Chapter 3. 

8. "In the 1991 Conpjter Society [of the Institute for Electrical and Electronic Engineers] 
membership survey, over half (54 percent) of the cunent full members polled indicated that they 
consider themselves software engineers, as did 40 percent of the affiliate men±)ers." Fletcher J. 
Buckley, "Defining software engineering". Computer (August 1993), p. 77. 

^ In the US, an "engineering program" (strictly so called) is one so accredited ty the 

Accreditation Board for Engineering and Technology (ABET, recently renamed "ABET, Inc."). 
ABET did not then accredit software engineering programs. 

' ° Not much has changed since the early 1990s. For details, see John R Speed "What Do 
You Mean I can't Call Myself a Software Engineer?" IEEE Software, November/December 
1999: 45-50. 

'' Johanna Ambrosio, "Developer Certification Bill Sparks Battle in New Jersey", 
Computerworld 25 (July 15, 1991), pp. 1, 81. In an email to Don Gotterbam a few days after 
these events (Septembers, 1991), Gary Ford reported: "A campaign by the American Society of 
Mechanical Engineers was successful in getting the phrase 'software engineer' changed to 
'software designer' throughout the bill. ASME seemed not to object to the term 'software 
engineer' per se, but wanted to reserve it for engineers that satisfied existing requirements 
(education, experience, passing a test) for licensed engineers." Ford (September 6, 1991) also 
reported similar legislation being considered (but not passed) in Texas, California, Ohio, and 
Tennessee. 

'^ Steven Levy, 'Down by Law: Excuse Me, Sir, But Do You Have a License for that 
HyperCard Stack?" Ma cVKorW, January 1992, pp. 73-82 

'^ Gary Ford and Norman E. Gibbs, A Mature Profession of Software Engineering 
(Software Engineering Institute, Carnegie-Mellon University: Pittsburgh, Pennsylvania, January 
1996), pp. 12-15. I should add that, originally, a "license" was a document someone would be 
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given (such as today's driver's license). Registration had a different administi:Btive apparatus, a 
list or registiy that could be checked if there was doubt about someone's status (such as today's 
voter registration roll). But this distinction is no longer sharp. Governments keep a record (a 
registry) of licensed drivers; and many jurisdictions issue a "registration card" (in effect a 
license) entitiing one to vote. 

^^ MitchBetts, 'Indusby debates certification", Computerworld 28 (May 2, 1994), p.l. 

'^ http://standaiiis.ieee.oig/ieadirig/iee^SB/Oct96/olituaries.htii^ (August 26, 2004) 
Buckley died in 1996 (at age 63). 

'^ I have not been able to track down the 'longmemo" referred to here. 

" "Report to the Board of Governors of the IEEE Conpjter Soddy from the Steering 
Committee for the Establishment of Software Engineering as a Profession" (Version: November 
15, 1993), Appendix 1, p. 6. 

" See, for exanple, David Lorge Pamas, "Software Engineering Programs Are Not 
Conpjter Science Programs", IEEE Software, November/December 1999: 19-30. 

' ^ Ford and Gibbs, A Ma tu re P rofessi o n, p. 1 5 . 

^° See, for exanple, an email from Paul Robinson (Tansin A. Darcos and Corrpaiiy of 
Silver Spring, Marylarid), dated September 1, 1993, and sent to Don Gotteibam's lists ETHCSE- 
LOUTKVMl.BITNET (CSEP Archive). Hostility to licensing has a long history in tiie 
professions— or, at least, in engineering. See, for example, Sarah K.A. Pfatteicher, "Depending 
on Character: ASCE Shapes Its First Code of Ethics", Journal of Professional Issues in 
Engineering Education and Practice 129 (January 2003): 21-31. 
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"Report" (November 15, 1993) Appendix 1, pp.6-7. 



^^ "Chikofsky: Memories" (notes from a phone interview, March 10, 2003), in CSEP 
Archive. 



23 



24 



25 



26 



Encyclopedia, v. I, p.95. 
Encyclopedia, v. I, p.95. 
[Frommemory (of lost email). Confirm (or disconfirm) in Chik)fsky interview.].***** 



Mary Shaw, "Prospects for an Engineering Discipline of Software", IEEE Software 7 
(November 1990): 15-24. Selected runner-up to best article in IEEE Software for 1990, it had 
already been reprinted in Donald J. Reifer (ed). Software Management, 4th ed. (IEEE Press: New 
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York, 1993), pp.486-495). It was soon to be reprinted m Encyclopedia of Software Engineering, 
V. II pp. 930-940. 



27 



http//www-2.cs.cmu.ediV^ifetin]dine/Dii]ffd.html (August 27, 2004). 

Encyclopedia, v. II, pp.1106-1107. 

Mario Baracd, Email to Davis, 27 January 2003. 

"Report" (November 15, 1993), Appendix 2, p.8. 

"Report" (November 15, 1993), Appendix 2, p.9. 

"Report" (November 15, 1993), pp. 1-2. 

The idea seems to be that engineers entering ("migrating" to) the United States (of which, 
in good times, there are generally a good number) might need re- training of a special sort. 

^* "Report" (November 15, 1993), p. 4. The c^tals here are an interesting device. They 
suggest that there exist departments of software engineering more or less on an equal footing 
with departments of corrpiter science. At that time, there was not a single Department of 
Software Engineering aryv\tere in the worid 

^^ "Report to the Board of Governors of the IEEE Corrpiter Society from the Steering 
Committee for the Establishment of Software Engineering as a Profession" (March 4, 1994), p. 
1. 
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"Report" (March 4, 1994), p. 2. 
"Report" (March 4, 1994), p. 2. 
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Chapter 3: SEEPPBe^ns^ 1994 



"Nothing is as easy as it looks." 
— The First of Murphy's Laws 



3.1 The Steering Committee 



By March 4, 1994, the time at which the lEEE-CS Steering Committee for the 
Establishment of Software Engineering as a Profession presented its final report to the lEEE-CS 
Board of Governors, the new lEEE-CS/ACM Joint Steering Committee had already been 
working for at least three months. Indeed, the handing off of work from one committee to the 
other was so smooth that there does not seem to be a day on which it can be said to have 
occurred. We can be sure that it was complete by March 4 because Mario Barbacci, chair of 
both committees, had presented the first report of the new Joint Steering Committee to the ACM 
a few days before (in Nashville, Tennessee). By then, he had a new vice-chair from the ACM, 
Dennis Frailey, ^ and a much enlarged commitbee, all member but one identified in the report 
with an "A" (for ACM) or "C" (for lEEE-CS) . The one exception, Patricia Douglas, n]en±)er ex 
officio because she chaired the body-of-knov\dedge task force, was a psychologist at IBM Skill 
Dyamics. Though in fact a mender of IEEE, she seems to have been treated as neutral. One or 
both of the following considerations explain her position: first, she seems to have had the trust of 
both the ACM and lEEE-CS; second, there was no one at the ACM (or ariyone else at lEEE-CS) 
v\to wanted to co-chair her committee. Defining the body of knov\dedge was a daunting task best 
left to experts. 

Six of the seven lEEE-CS men±)ers should be familiar from Chapter 1. Barbacci himself, 
Buckley, Chik)fsky, and Druffd were from the original committee. Two of the ex officio 
men±)ers. Carver (Curriculum) and Mdford (SEEPP), were from old lEEE-CS task forces (now 
lEEE-CS/ACM task forces). The one new lEEE-CS face, an "ex officio", Ron Hbelzeman, is an 
academic (Electrical Engineering-Conpjter Engineering, University of Pittsburgh), ^Dparently a 
replacement for Schneidewind^ 

Three of the seven ACM men±)ers are also familiar from Chapter 2.3. Zweben had served 
as the ACM representative to the old lEEE-CS Steering Committee. John Werth,^ the new co- 
chair of the curriculum task force, had been (and was still) one of the Vice Chairs for Education 
of the IEEE Technical Council on Software Engineering (TCSE).* Gottertam, now co-chair of 
the ethics task force, had been active in eariier lEEE-CS discussions of licensing.^ Maiy Shaw is 
familiar for another reason, her extended critique of Buckley's original proposal at the TCSE 
meeting (2.4). The two other ACM ^Dpointees— Bany Boehm and Stuart Fddman— are new. 
Both would have carried considerable authority with other ACM men±)ers. 

Bany Boehm holds a BA. (Harvard, 1957), M.A. (UCLA, 1961), and PhD. (UCLA, 
1964), all in math He had worted at TRW from 1973 to 1989, ending his career there as Chief 
Scientist of the Defense Systems Group. Between 1989 and 1992, he was at the U.S. Department 
of Defense, serving as Director of the Information Sdence and Technology Office, Defense 
Advanced Research Projects Agency (DARPA), and as Director of the Software and Conpjler 
Technology Office, Defense Department Research and Engineering (DDR&E). Since autumn 
1992, he had been TRW Professor of Software Engineering, Conpjter Sdence Department, 
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University of Southern California. He had authored several books, including Software 
Engineering Economics (Prentice Hall, 1982), Controlling Software Projects: Management, 
Measurement, and Estimates (Prentice Hall, 1986), and Software Risk Management (IEEE 
Computer Society Press, 1990), all then still in print.^ 

Fddman was at Bdl Communications Research, Inc. ("Bdlcoie", now Tdcoidia 
Technologies) in Livingston, New Jersey. He hdd a management position in sofbA/aie 
engineering and conpjting systems and was the Technical Leader of the Tdecommunications 
Infonnation Netwoildng Architecture Consortium, an international research group of 
tdecommunications and conpjting con^Miies. Fddman hdd an A.B. in Astropliysical Sciences 
and Mathematics (Princeton, 1968) and a PhD. in Applied Mathematics (MET, 1973).' 

As we look over this list (ignoring Douglas), we can see an obvious pattern. The Steering 
Committee is joint in a more conplicated way than the offidal rationale admits— and divided in 
a way never offidally stated On the one hand, all the ACM men±)ei:s are (as a matter of fact) 
also members of lEEE-CS. This is not as surprising as it may seem The men±)eiship overi^ 
was (and remains) considerable. Some estimates are that 90% of ACM members are also 
men±)eis (or affiliates) of lEEE-CS (with only a somev\tot smaller percentage running the other 
direction because the lEEE-CS is somev\tot larger).^ What we have, thea is not a distinction 
between lEEE-CS members of the Joint Steering Committee and ACM men±)ers but merdy 
between lEEE-CS appointees and ACM appointees. What explains the overlap? Or, to put the 
question another way, what explains the continuing existence of both ACM and lEEE-CS? Why 
have they not long since merged? 

The overlapping membership seems to have a relatively pedestrian explanation. Neither 
lEEE-CS nor ACM is a professional society (strictly so called) but a scientific or technical 
society, that is, an organization (formally) held together by interest in a field of knowledge 
(rather than, as a professional society would be, by occupation). To join lEEE-CS, one has to 
meet only one of the three criteria: a serious interest in any aspect of the computer field, 
membership in an affiliate society, or membership in IEEE or another IEEE society. Of the three, 
the hardest to satisfy may seem to be IEEE membership. But even that was not (and is not) hard 
for most ACM members. To join IEEE (as a "member", as opposed to an "affiliate")^ one only 
needed a bachdor's degree from an ABET-acaedited program or a C SAB -accredited program 
(or, absent such a degree, what the admissions committee would count as three years of 
experience in a position normally requiring such a bachelor's degree).'" To join the ACM, one 
needed only a bachdor^s degree (in any fidd), the equivalent levd of education, or two years 
full-time errployment in information technology.'' Most members of ACM would have had 
more than two years full-time employment in information technology (in a position normally 
requiring a bachelor's degree), making them eligible for membership in IEEE (and so in lEEE- 
CS). 

Why are there two organizations rather than one? The answer seems to be that, on the 
whole, they do different things. lEEE-CS shares with the rest of the IEEE a set of practical 
concerns characteristic of engineering, especially development of technical standards. The ACM, 
in contrast, is more concemed with the science of computing (especially, the mathematics of 
computing) and with the computer science curriculum. The two associations hold different sorts 
of conferences, publish different sorts of journals, and otherwise work side by side rather than in 
direct competition. Collected Algorithms or Transactions of Programming Languages and 
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Systems is a typical ACM journal; the lEEE-CS equivalent would be Computer or Transactions 
on Mobile Computing. 

The explanation of this cohabitation is probably history rather than logic. The two 
associations began about the same time, one as a special interest group within an engineering 
society and the other as an independent society concerned more with the applications of 
computing machinery (what we now call "programs" or "software") than with the design of the 
machines themselves (engineering). As software became an ever larger part of the "machine", 
the distinction between engineering and applications became ever harder to make. Indeed, the 
term "software engineering" may be understood as a declaration that applications were as much 
in need of engineering as the hardware was. Nonetheless, there remain significant differences 
between the two organizations. Perhaps the most important is that the ACM has always had a 
stronger identification with student organizations in departments of computer science than lEEE- 
CS has. 

3.2 The Odd Couple: Melford and Gotterbam 

These differences between the two societies may explain an important difference between 
ACM appointees and lEEE-CS appointees. All but one of the lEEE-CS appointees (Melford) 
have at least one (ABET-accredited) degree in engineering (or the non-US equivalent). None of 
the ACM appointees does. In contrast, all but one of the ACM appointees (Gotterbam) have at 
least one degree in mathematics. The exceptions confirm what we know about the flexibility of 
the formal membership requirements of the two organizations. 

Melford, a member of both organizations, was not an engineer; indeed, he was not even a 
college graduate. (When he left California State University at Irvine two years before graduation, 
his major was economics, though he had planned to study electrical engineering.)^^ He joined the 
IEEE in the eariy 1980s because a colleague encouraged him to. (By then, he had three years 
experience in security ^Dplications of sofbA/are that would ordinarily be done by people with a 
bachelor's degree in conpjter science or engineering; hence, there was no problem about his 
rneniDeiship even though he vvas not trained as an engineer.) Some years later he got a broadcast 
mailing from the lEEE-CS saying that the Commitbee on Public Policy (COPP) had started an 
ethics subcommitiiee and asking if he was interested in joining it Because he had concluded that 
most problems with software were ultimately problems with those v\to wrote software, he 
joined By the time the Steering Committee was setting up the task forces, Melford was COPF s 
chair, an obvious choice for lEEE-CS co-chair of the ethics task force.' ^ 

Donald Gotterbam, the ACM co-chair, differs from Melford in at least three inpjrtart 
ways. First is education Gotterbam had a lot more of it (and v\tot he had was quite different 
from Melford' s). GotberiDam holds a B.A. in philosophy from Hbfstra University (1964); a 
Master of Divinity from Colgate Rochester Divinity School (1967); and an MA. (1970) and 
PhD. (1971), both in philosophy, from the University of Rochester. (Hs dissertation's title is 
Natural and Philosophical Relations in David Hume.) He taught philosophy at Wichita State 
University (Kansas) for three years (1971-74), tuming down early tenure to accept an untenured 
assistant professorship at the University of Southern California's School of Philosophy. From the 
perspective of most philosophers, to teach at WSU is to toil in the lower reaches of academy's 
Purgatory; to move from there to USC, to rocket into its Heaven. So, what happened two years 
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later should surprise. In 1976, Gotterbam left USC for Harrisburg, Pennsylvania, without even a 
job in hand. 

There were several reasons for leaving USC just two years after he arrived. Both 
Gotterbam and his wife were Easterners much farther from relatives than they had been in 
Kansas. Though they had grown up in New York City, they had developed a strong dislike for 
Los Angeles. These reasons, and perhaps others, led to the sudden re-direction of Gotterbam's 
career. 

For the Spring Term of 1977 and again for the 1979-80 academic year, Gotterbam taught 
philosophy part time at Dickenson College (in nearby Cariisle), more because he liked teaching 
than because he needed the money. He made his living as a programmer. 

Gotterbam's preparation for programming was similar to Melford's, that is, he was (more 
or less) self-taught.^'^ Having learned symbolic logic as part of his training in philosopliy, he 
supplemented v\tot he could teach himself from bools on programming by sitting in on 
conpjter science courses at WSU and USC. To inpDve his job prospects in Hanisbuig, he 
entered a two-year program in conpjting at Hanisliiig Area Community College, graduating 
with an Associate of Arts (A.A.) in corrpiting in 1979. (At the time, the A A. was a recognized 
credential in ^Dplied corrpiting.) 

A secorii difference between Melford's background and Gotterbam's is their respective 
careens within conpjting. Gottertem' s early conprting career is similar to Mdford' s (and was 
roughly contenpjraneous with it). From 1976 through 1984, Gotbertem worted as a 
programmer, moving quickly from sinple programming to systems devdopment By the early 
1980s, he had his own consulting firm As a consultant, he did work on Medicare programs for 
Blue Cross Pennsylvania, hdped Blue Cross devdop networks between several of its regional 
operations, and devdoped inventory tracking systems for the US government's Ship Parts 
Control Center in nearby Mechardcsburg and a similar facility in Philaddphia 

But, for all this practical experience, Gottertem seems to have remained an academic. 
While there is a gap of fifteen years in the Philosopher's Index between his last publication 
concerned with Hume (1976) and his first publication concemed with computer ethics (1991), 
those years were not without publications. Gotterbam's curriculum vitae lists (in addition to what 
the Philosopher's Index has for these years) the following: "James' Theory of Cognitive 
Knowledge", Bicentennial Symposium (1976);"Tipton on Berkeley's Immaterialism", 
Philosophia (1979); and nine entries for the American Academic Encyclopedia (1980).'^ 

For the first few years after leaving USC, Gotteibem seems to have tried to teep up with 
devdopments in his old fidd, the history of modem philosophy. But, more inpjrtant, he began 
to identify ethical questions in the programming he was doing. The first such question concemed 
the transfer of some medical dedsions until recently made by physidans, nurses, and other 
"health care providers" with direct knov\dedge of the patient, to conpitens or to distant Blue 
Cross enployees with a conpiter assistant (an expert system). What responsiMities did 
programmers v\to designed or built the necessary software have as a result of this transfer of 
dedsion-making to people unable to see the consequences of thdr own decisions or to evaluate 
the assun^Dtions on v\Mch the software was constmcted? Did the programmers have the same 
responsiMities to patients as physidans did? Or greater responsUilities because thdr software 
had a much larger inpact on patients than the decisions of ariy single physidan could have? 

Gotterbam had also begun to work part time as a "faculty tutor" in the conpiter sdence 
lab at Harrisburg Area Community College.' ^ Some of his students might (he realized) soon be 
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helping to design and build nuclear weapons. Was it right to teach them the programming skills 
they would need to do that? Then, in 1983, President Reagan announced the Space Defense 
Initiative (a space- based defense against nuclear missile attack heavily dependent on software of 
a scale, complexity, and reliability well beyond anything yet attempted). Here was another set of 
questions to consider. Many programmers doubted anything like the specified system could be 
built for several decades, if at all. They were also concerned that any system much like that 
proposed could only be trusted if it could be adequately tested under realistic conditions and such 
testing was not practical. (Who would want nuclear explosions going off a hundred miles or so 
above their heads?) Should programmers nonetheless work on such a project, since the technical 
problems were interesting and the money was good? What responsibility did programmers have 
to tell the truth about what they did, to warn clients and public about the risks inherent in a 
program too complex for anyone to understand, about the limits of what could be accomplished? 

The similarity between Gotterbam's career and Melford's ends here. By 1983, Gotterbam 
was tired of consulting. (For him, too much of consulting was winning the contracts to do the 
work; his interest was the work itself.) So, in early 1984, he took a salaried position at a Scranton 
bank, designing electronic fund-transfer systems. (Scranton is about 120 miles north of 
Harrisburg.) When, a few months later, the bank was taken over by a larger bank uninterested in 
computer research, Gotterbam turned down its offer of a position managing programmers to 
become a (much- lower- paid) assistant professor of computer science at Alleghany College (in 
Meadville, Pennsylvania, almost 300 miles west of Harrisburg). There he taught basic computer 
science courses and developed some new courses. Most of the new courses, such as one in 
database design, were technical. But one, a course in computer ethics, combined the technical 
with the ethical. Students actually developed software and reviewed technical documents looking 
for technical as well as ethical errors. 

Gotterbam was particularly well- suited to teach computer ethics. For many professors of 
computer science then, a course in computer ethics was not a computer science course at all. For 
them, computer science was a kind of mathematics, very far from practice. Computer ethics was 
a kind of ethics. Philosophers taught ethics. Gotterbam's Ph.D. in philosophy thus seemed to 
make him the ideal person to teach the course. Gotterbam also thought himself the ideal person 
to teach the course, but not (primarily) because of his training in philosophy. Unlike his 
colleagues, he had done programming "in the real world". He had, he liked to say, written 
programs that, written incorrectly, could kill people. He could convey to his students the 
uncomfortable tmth that programming was not mere mathematics but a practical activity capable 
of doing great harm as well as great good. Part of avoiding harm was writing programs that met 
certain standards, standards of ethical conduct as well as of competent programming. Indeed, 
competent program was an ethical imperative (as well as a technical diseratum). 

Courses in computer ethics were still rare enough then to be news. In 1988, the Chronicle 
of Higher Education carried a story entitled "Failure of Colleges to Teach Computer Ethics is 
Called an Oversight with Potentially Catastrophic Consequences". Gotterbam was quoted in the 
article— along with another philosopher, Deborah Johnson (whose textbook Computer Ethics 
was described as one of the few in the field). ^^ 

During the years in Harrisburg, Gotterbam had not had time to put his thoughts about 
conpjter ethics on p^:er. He had been doing too much else. Now, an academic again, he began 
to write— and to real v\tot he was writing at conferences. The first of v\tot would soon be marry 
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papers was "The Roles of Computer Ethics in the Curriculum", presented at the Conference on 
Computing and Undergraduate Education held at Carnegie Mellon University (1987). 

Meadville is only 90 miles north of Pittsburgh where (as explained in Chapter 2.1) the 
Software Engineering Institute (SEI) opened on January 1, 1985. Gotterbam was soon attending 
SEI seminars and conferences. Some of SEI's first initiatives were educational. These included 
an attempt both to define a curriculum for software engineering and to raise the technical 
competence of software engineers already in practice. These were major undertakings. (At the 
time, as Gotterbam recalls, the chair of his computer science department liked to say, "Software 
engineering is just about documentation."). Gotterbam approved of both initiatives. By late 1987, 
he was inquiring about participation in some of SEI's educational initiatives. 

In 1988, Gotterbam went back to Wichita State, becoming an assistant professor of 
computer science. The move is not as surprising at it may appear. WSU's department was the 
first to experiment with a Masters of Software Engineering using a curriculum SEI was 
developing. WSU thus gave Gotterbam the chance to cooperate with SEI in the development of 
courses, to test them, and to help SEI draw from the results educational materials that could be 
distributed to other universities trying to establish similar programs in software engineering. 

Early in 1989, Gotterbam presented a paper on ethics at SEI and lobbied SEI staff to 
include ethics in the new curriculum. The lobbying proved effective. Gotterbam was named a 
Visiting Scientist at SEI for the summer and asked to develop educational materials to be used in 
software engineering classes, including some materials on ethics. It was then, Gotterbam 
believes, that he coined the term "software engineering ethics" to describe the ethical 
responsibility of software developers in the practice of their craft.^^ In ariy case, he began the 
summer with the first Software Engineering Ethics Worlshop. It was there that he met conpjter 
scientists, Keith Miller (then at the College of William and Mary in Virginia) and Joyce Currie 
Little (Towson University, Maryland), both of v\tom had undergraduate degrees in (math) 
education (as well as PhD.' s in conpjter science). He would later recruit both for SEEPP. 

By fall 1989, Gotterbam knew a good deal more about WSU's conpjter science 
department than he had a year earlier. It was a less h^Dpy organization than it had seemed at first 
arri, because of a new chair, less committed to software engineering. Gottedem therefore began 
looking for another job. He soon found that East Tennessee State University (ETSU) was 
looking for someone to teach software engineering courses and to start a master's degree in 
software engineering following the SEI model. 

ETSU had other attractions to condensate for its isolation in northeastern Tennessee. 
Johnson City, with a population of about 60,000, was the size that Gotteatam had found he lited 
The location, a long valley, with the blue-ridged foothills of the Great Smotey Mountains rising 
abmpdy on either side, was at least as beautiful as aiiything he had seen in Pennsylvania— and 
quite unUte the plains of Kansas (or the smoggy hills of Los Angeles). The university was of 
medium size (about 10,000 students) with a spacious canpjs of grass, trees, and streams. Its 
buildings spread out as if land were plentiful arid che^. Most of the buildings were of red brick 
with v\Mte trim in one approximation or another of Georgian colonial, giving the place an eastern 
look. Gilbert Hall, one of the oldest buildings on canpjs, was v\tere Gotterbam would have an 
office on the second floor, along with the rest of Conpjter Science (Mathematics on the floor 
below). Almost a century old, with an inpressive fagade, Gilberts interior was nonetheless 
utilitarian and undistinguished Of course, the chief attraction of ETSU's conpjter science 
department was not its offices. ETSU's department was "^plications oriented", indeed, so 
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applications oriented that it already had a course in computer ethics. Gotterbam did not have to 
explain to that department why it was important to teach computer ethics— or that a course in 
computer ethics was a computer course, not a philosophy course. He arrived in the fall of 1990 
as an associate professor, moved into a windowless office, and has taught there ever since— 
except for an occasional visiting professorship elsewhere. 

It was also about this time that Gotterbam became a "Distinguished National ACM 
Lecturer" on ethical issues in computing (as wells as on fiber optic computers and new 
developments in telecommunications).^^ Gotbedem was devdopng a reputation among ACM 
members interested in conpjter ethics. 

3.3 The AMC Code 

A third difference between Mdford and Gotterbam is that Gotbertem had had some 
experience in writing a code of ethics before joining SEEPP, vMle Mdford had none. GotberiDam 
hsd hdped to write the present ACM code of ethics. In 1991, Ronald E. Anderson, a former 
president of the ACM Special Interest Group in Conpjters and Sodety (SIGCAS), recdved a 
grant from ACM to revise its Code of Professional Coriluct, adopted in 1972.^ ° This was the first 
offidal endorsement of a project Anderson had already been activdy working on for at least a 
year. He had begun that work at an all-day synposium at the first Conpjters and Quality of Life 
Conference (1990). Anderson presented ideas derived from that meeting at other meetings.^' 
Now, grant in hand, he recruited from attendees at the annual Conpjters and Sodety Conference 
(Febmary 1991) a dozen people to produce a draft Among those recnited, besidie GotteriDam, 
were two professors of conpiter sdence v\tom GotieriDam would later recruit as wdl (Diarme 
Martin and Laurie Wertii) } ^ 

Over the next five months, Anderson prepared a "rough draft"— which he distributed at 
the Conference on Computing and Human Values, sponsored by the National Science 
Foundation and hosted by the Research Center for Computing and Society (RCCS) at Southern 
Connecticut State University (New Haven), in August, 1991. He also sent a copy of this draft to 
the ACM Council (the ACM's governing body).The Council's reaction illustrates how careful a 
drafting committee should be about who sees its early work— or, at least, about how it is 
presented. The Council's reaction to Anderson's rough draft was not good. The primary reason 
(he soon learned) was that Council members supposed that the rough draft was the final draft. 
Once that misunderstanding was cleared up, there remained a number of substantive criticisms. 

At the Conference on Computing and Human Values, Anderson found the people he 
needed (about fifty) and the free late afternoons and early evenings to rework the rough draft. He 
presented the rough draft along with the criticisms he had collected. By the end of the 
conference, he had a presentable "first draft" .^^ 

Anderson distributed this offidal draft to the ACM Coundl. The Council responded 
Anderson' s drafting committee then revised accordingly (working in part at least by email). He 
sent the Coundl the revised code and recdved further responses v\Mcli he tried to incorporate as 
he had bdore. Anderson was also presenting the draft at various ACM-sponsored meetings, 
collating responses from his audiences. Eventually, Anderson had v\tot he supposed a final draft 

The process of creating a code of ethics, espedally winning adoption, is always 
"political" (that is, an activity requiring partidpants to work together voluntarily, winning by 
persuasion v\tot cannot be conpdled). Ariything from otgective considerations (whom the code 
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would help or hurt) to personal taste in language might decide the outcome. As the drafting 
committee came to appreciate who wanted what and why, it revised the code accordingly. So, for 
example, Imperative 4.1 now simply urges ACM members to "Be fair and take action not to 
discriminate". Originally, it included a short list of prohibited subjects of discrimination, but 
various special interest groups wanted to add their own favorite to the list. To avoid a long list, 
the drafting committee decided to make it clear that the list was not intended to be exhaustive. 
The committee did that by moving the entire list from the Imperative to the corresponding 
Guideline. The generality of the Imperative now captures all types of discrimination. The 
Guideline provides enough specificity ("race, sex, religion, age, disability, national origin, or 
other such similar factors" ).^^ 

The draft that emaged from this process was published in Communications of the ACM 
(May 1992) with a ballot asking members to vote on each item in the code. The vote was 
favorable for all provisions— clearing the way for the final Council approval. Then, a few days 
before the Council's meeting, Anderson learned that some Council members might vote against 
the new code because they believed it would not be useful in decision-making. (The Council 
included some members who had helped to write the code this new one was to replace.) 
Anderson asked Gotterbam and Deborah Johnson to help write a paper showing the new code's 
usefulness in ethical decision- making. (By then, Johnson's text in computer ethics was widely 
used.) The three quickly wrote the paper, "Using tiie ACM Code of Ethics in Decision Making", 
and presented it at a Council meeting the morning of October 16, 1992.^^ 

Since the presentation went well, neither they nor Anderson stayed for the afternoon 
session at v\Mch the code vvas to be approved. TTiatniay have been a nnstcte. TTieCtoi^ made 
a number of revisions before coming to a final vote. One of those revisions was significant 
(weaterdng the clause providing for penalties for disobeying the code). To this day, Gotterbam 
believes that the drafting commitbee could have prevented those revisions had it been there to 
explain v\^ it had written the code the way it had One lesson Gotterbam took from that 
experience is that those v\to know niost about a proposed code shoidd be present at ddibera^ 
concerning it until final ^jproval. One cannot expect those v\to have not worl^d on the drafts 
and partidpated in extended disciissions about than to understand the final draft as vvell as to 
vto did^ ^ Another lesson he might have drawn from his experience with writing the ACM code 
was that even a large organization could write a code of ethics in eighteen months. 

3.4 SEEPP Gets Started 

Gotterbam first met Barbacd on Noven±)er 16, 1993." Gotterbam was at SET on 
business unrelated to the Steering Committee' s worlc In the morning, he video-t^:ed a graduate 
class on professional issues in software management (By then, SEI had a substantial distance 
education program) In the afternoon, he made a CD for SEI' s "Just in time education program". 
(SEI could generate CDs quickly in response to hot topes, marteting them to industry.) Between 
these activities, over lunch, he met with Barbacd. Barbacd believes Gotterbam arranged the 
meeting.^ ^ (Gotterbam does not remember.) Its official purpose was to "discuss" the lEEE- 
CS/ACM joint project Barbacd stefched the plan so far devdoped, gave Gotterbam copes of 
the minutes of the rdevant meetings of the lEEE-CS Board of Governors and ACM Coundl, and 
asked about his interests, experience, and oprdons. Barbacd also asted v\tether Gotterbam was 
interested in partidpating in the project He answered that he was. 
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A few days after the meeting, Gotterbam decided to put his thoughts in better order. The 
result was a three- page single-spaced memo commenting on specific passages in the documents 
he had received. To this he added a copy of a paper he had written on licensing and emailed the 
package to Barbacci. The gist of the paper was that licensing was not an end in itself but a way to 
enforce standards, especially, standards of skill. The gist of the memo was that neither the lEEE- 
CS nor the ACM seemed to have a good grasp of what goes into making a profession; they 
certainly did not agree with Buckley that software engineering should be a profession. Getting 
agreement on significant standards was worthwhile, but significant standards had to be detailed, 
more detailed than either the lEEE-CS or ACM document suggested. Gotterbam seemed to be 
advocating (what he would later describe as) "standards of practice" rather than a "mere" code of 
ethics. Neither the memo nor the accompanying paper has much to say about ethics. Indeed, the 
memo ends with a postscript asking, "How does ICCP [Institute for Certification of Computer 
Professionals] fit into the effort to define skills?"^^ Nov\tei:e in the memo does Gotbatem 
express any idea that he might co-chair one of the task forces (though he does thank Mario for 
"giving me the opportunity to participate"). 

Nonetheless, Gotterbam was soon offered the opportunity to co-chair the ethics task 
force; he accepted; and, on January 29, 1994, Barbacci met with lim and Mdford in Pittsburgh 
to get the task force started The meeting took place in the same SEI seminar room in which 
Gotterbam had held his first worlshop on software engineering ethics (1989). There was an 
irory in this. By 1992, thinking about ethics had changed at SEI. Norman Gibbs, then the 
Director of SEI's Education Division, had told Gotterbam, "Ethics is not relevant to software 
engineering" and, proving he meant v\tot he said, announced that SEI would not be publishing 
the curriculum module on ethics Gotterbam had prepared Now, less than two years later, ethics 
was back at SEI (if only on a weetend and only because Barbacci had his office there).^ ° 

This was v\ten Gotterbam and Mdford first met There was a long agenda The meeting 
went wdl. The three began ty refining (or broadening) the task force's assignment The task 
force had been told (two months before) to devdop a "code of ethics". The January minutes 
(Mdford' s) announce that "Codes of Ethics [are] (not equal to) Standards of Conduct", 
distinguishing them in this way: A code of ethics merdy "identifies conflicts". Standards of 
conduct provide: "a) Guidance to resolve conflicts [between users, devdopers, enployers, 
regulators, and others], b) Standards of quality, and c) ResponsiMity for understanding the 
inqiications of one's work." This distinction seems to explain the name ty v\Mch the minutes 
refer to the task force for the first time, something that seems to need explanation (in part, at 
least because the Steering Committee had created a task force to write a "code of dhics" and 
said nothing about "a code of professional practice"). The three had to rgect (or ovedook) the 
obvious name for the task force, the "Software Engineering Ethics Task Force", with its pleasant 
acronym, "SEE", for "Software Engineering Ethics and Professional Practices", with the 
unpleasant hint of ooze in the acronym "SEEPP". The three were unhappy enough with 
"SEEPP" that they agreed to find a better name "later". But events preempted good intentions. 
SEEPP had to use its name publicly before a better one could be found— and then a better would 
have had to be bought at the price of some confusion.^' 

The term "professiorial practices" suggests standards of conduct something more than 
just "ethics". In chDOsing to include "professional practices" in the task force name, the three 
may seem to have been committing SEEPP to report something more than a code of ethics, that 
is, a "code of practice". There is, however, another interpretation— for Gotterbam, at least The 
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three-page memo he had sent Barbacci after their first meeting (November 16) included the 
following comment (concerning "page two"): 

In general I would suggest keeping constantly coupled the phrases "ethical conduct and 
professional practice." The definitions of professional you included do not indicate the 
contractual nature of a profession. The theoretical contract of professionalism says that 
"by virtue of having a specialized skill and being allowed by society to maintain control 
over this skill, society is due a HIGHER standard of care from the (licensed) professional. 
Ethical conduct is tied to professional practice.^^ 

For Gotbertem, then, the point of joining "ethical conduct" with "professional practice" is (in 
part at least) to stress that "professional practice" is "ethical conduct" (conduct made ethical by a 
moral "contract" between profession and society). 

The commitment to something more than a code of ethics, if there was then such a 
commitment, may explain something else all three agreed to: adopting the IEEE's "Standards- 
development model" (even though the Joint Steering Committee and its subcommittees belonged 
to the ACM as much as to the IEEE). For the IEEE, any Standard-developing committee (or 
other committee assigned a large project) becomes a "steering committee" that oversees the work 
of several "task forces", one task force for each major division of the project. Each task force 
consists of several "working group leaders", one leader (or occasionally more) for each 
subdivision of the project. Each working group leader oversees a specialized working group and 
reports back to the task force. The three agreed on a preliminary list of working groups: privacy; 
security; testing and reliability; professional competence; duties to society; intellectual property; 
and ethical tools.^^ 

The three also agreed to follow IEEE procedures for writing "Standards" (the capital "S" 
signaling a certain sort of standard). For the IEEE a standard (with a small "s") is a general 
category consisting of "Standards" (with a c^tal "S"), "recommended practices" (maited by a 
"should" rather than the "shall" of a Standard), and "guides" (more than one practice can be 
recommended). Because Gotterbam knew littie about IEEE procedures, Mdford undertook to 
prepare the required "Call for Participation" (CEP) the IEEE way. This is the first sign of a 
pattern that would endure for almost two years— with neariy disastrous consequences (as we 
shall see in subsequent ch^Dters). Gottedem, the ACM' s co-chair, would defer to Mdford (and 
Barbacd) on SEEPP procedure because the IEEE seemed to have (and actually did have) a good 
deal of experience writing standards, much more experience than the ACM, and writing a code 
of dOoics-and- professional- practice seemed to be much more like writing other IEEE standards 
(whether Standards strictiy so called, guidelines, or mere recommended practices) than like 
writing a mere code of ethics. 

The three did not, however, rely entirely on the Call to bring in participants in the 
numbers and variety they wished. They had already recruited three members for the task force: 
Joyce Currie Little, identified in the minutes as an "educator"; Keith Miller, as the "ACM 
ethicist"; and Gerald Engel (newly returned to teaching after several years on loan to the 
National Science Foundation), as the "Grant Funding Advisor".^* Gottedem undertook to find a 
corporate ethics officer, and a lawyer with interests in malpractice, negligence, liatality, and 
intdlectual property. Mdford undertook to contact some other "etlidsts" (Patrick Sullivan and 
Michad McFariand); some experts in the IEEE' s Standards process (Leonard Tripp and Fletcher 
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Buckley); and the chair of the lEEE-CS ethics subcommittee that Melford had himself once 
chaired (Suzanne Weisband). While there was agreement that the task force or its working 
groups should include "technologists", no one undertook to recruit any (perhaps because most of 
those already identified for other purposes fit that description). 

Last the three set a target date for completion of the work of the task force, November 
1995. The task force would have twenty-two months, four months more than Anderson's 
committee needed to write the ACM code (and win its approval). The three sketched a tentative 
schedule, beginning with the next meeting ("#1") to be held on Saturday, April 30, 1994, and 
(after "meeting #4") ending with "Submit (Nov. 95) report and draft to [lEEE-CS] BOG".^^ 

Tte ageo[fe of the planned next nieeting (April 30) vvas airilitious. T^ 

1 . Revise Task Force schedule, 

2. Partition/categorization of standards, 

3. Funding grants, 

4. Establish deadlines for WG [working group] draft standards, 

5. Conplebe email/conferencing/public bulletin board, 

6. Forrriulate draft PAR [Project Authorization Request] (for internal use only) to identify 
conponents for successful submission, 

7. Prepare call for participation (CFP) in working groups, 

8. Identify audience and time limit for CFP (e.g. 30 days), 

9. Identify WG chairs (continues) .^^ 

3.5 PAR in DC? 

On April 24, Melford sent out an official agenda for the April 30 meeting; it summarized 
the January 29 meeting, refined the agenda items, and allotted time for each item (for exanqie, 
"9:15-10:00, Define Scope of ethics TF [task force]; 10:00-10:15, Revise Task Force Schedule; 
10:15-10:30, Library research identify titles^documents, identify 'v\to gets v\tof , and document 
repository")- The meeting was to end some time after 3:00 pm— after the task-force schedule had 
been "revised (again)". 

The timing and location of the meeting deserve comment The meeting was scheduled in 
Washington, DC so as to come just after the annual meeting of the Conpjter Ethics Institute 
(CEI). The CEI was a good place to advertise SEEPP— as well as an inportant c^tal in the 
geography of conpjter ethics. CEI began in the mid- 1980s as the Coalition for Conpjter Ethics, 
a local discussion group. Support came mostly from IBM, the Brookings Institution, and the 
Washington Theological Consortium, as did most participants. In 1992, it formalized itself as 
CEI, a project of Brookings. Though similar in name to SEI, CEI was (and remains) a quite 
different entity, "an advanced forum and resource for identifying, assessing, and responding to 
ethical issues associated with the advancement of information technologies in society". CEI is 
supposed to stimulate awareness of ethical issues in technology by consultation, research, 
education, and public outreach, but not to set standards (though it did develop "The Ten 
Commandments of Computer Ethics"— a short code designed for all computer users— in the 
early 1990s). CEI's primary focus seems to be organizing events bringing together people 
interested in public policy issues related to computers (both hardware and software)." 
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Melfond had been active in CEI from the late 1980s. That was how he knew Patrick 
Sullivan, its executive director since 1991. Sullivan was a philosopher (Ph.D. from the 
University of Kentucky, 1988, dissertation on Pierce's speculative rhetoric) who (like 
Gotterbam) had developed an interest in computing. But (unlike Gotterbam) Sullivan never 
became a programmer, much less a software engineer. Having followed his spouse to 
Washington in 1991, he combined some teaching (everything from introduction to philosophy at 
a small college nearby to the graduate bioethics continuing education program at Johns 
Hopkins). CEI was an ideal place for a philosopher to meet others with a sophisticated 
understanding of computer ethics.^^ Sullivan had met Gotbertem at an earlier CEI conference. 
So, v\ten Mdfoid suggested that Gotbedem be invited to participate in CEI's third annual 
Conference on Conpjter Ethics (Building Ethical Culture in Cyberspace: Further Pursuit of a "Ten 
Commandments" for Computer Ethics), Sullivan was h^DRy to arrange a panel at which Gotterbam 
(along with Mdf ord) could discuss software engineering ethics. (The invitation meant that ETSU 
could cover Gotterbam' s travel costs— inpjrtant because SEEPP still had no budget) 

SEEPFs meeting was held, as planned, at the Washington headquarters of the lEEE- 
CS— but that seems to be the only thing that went as planned No nnniites survive but, in a nie^ 
written a year later, Gotteatem described the meeting in much less ambitious terais than the 
agenda had. A "get acquainted meeting", it was a small affair, with only Gotteatam, Mdford, 
Steve Barber (a lawyer v\tom Gottertem had met a few weeks before)^ ^ , Little, Sullivan, Ramon 
Barquin (president of CEI and a founder of the Coalition v\ten he was at IBM), and Elliott 
ChikDfsky (Steering Committee men±)er v\to h^Dpened to be in town) physically present*" 
Buckley and Tripp partidpated by conference cdl. The discussion could not advance much 
beyond January 29 because the documents that such an advanced discussion presupposed (a draft 
of the Call for Partidpation, the PAR statement and so on) were not ready. Gottertem recalls 
Mdford asking Tripp detailed questions about how to prepare a PAR— with no one dse present 
having ariy idea v\tot they were talking about Barber just remen±)ers "a tdephone conference 
with an IEEE process gum that seemed to go on forever with no real bendit SEEPP members 
familiar with the process gum engaged in quite a hat of eye-rolling."* ' 

3.6 Report to Steering Committee 

On May 28, 1994, at the Software Engineering Institute, the Joint Steering Committee 
hdd its next official meeting (starting at 10:00 and ending at 5:00, with an hour for lunch). All 
Committee members were present except Buckley, Mdford, and Shaw.*^ Each task force 
reported, beginning with the body of kriowledge (Douglas) and ending with the curriculum 
(Carver and Werth). What each reported was a stetch of the work ahead 'Discussion" followed 
The meeting's minutes use one page single-spaced to summarize the three reports but three-and- 
a-half pages to summarize the 'Discussion". Of those three-and-a-half pages, about two thirds 
concern the body of knov\dedge, with the remainder divided evenly between curriculum and 
ethics. (The schedule of the meeting reveals a similar enqliasis, with the body of knov\dedge 
recdving seventy-five minutes to sixty for ethics and forty-five for curriculum) Cleariy, for the 
Steering Committee, defining the body of knov\dedge was the most interesting, or at least the 
most troubling, part of thdr project But our concern is SEEPP. 

GotberiDam spote for his task force. All members of a profession have obligations 
because they bdong to that profession. Reflecting on the obligations of other professions, the 
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task force identified three "orthogonal axes" by which other professions organize their special 
obligations. One is the groups to which they have special responsibilities (the individual the 
organization, the society). A second axes is the standards from which the obligations derive 
(justice, equity, privacy, autonomy, beneficence, avoidance of harm, fidelity, integrity). The third 
axis is defined by problems (privacy, security, testing and reliability, competence, duties to 
society, intellectual property, and ethical tools) .^^ The point, ^Dparently, was that though SEEPP 
seemed so far to be working as if the third axis (the problems) were the only possible axis, it was 
aware of the other two. The other two were certainly potentially inqxDrtanL For exanqie, the old 
IEEE code of ethics (1987) was organized ty group, vMle the new one (1990) was organized ty 
standard 

Gotierbam also indicated that SEEPP intended to follow the IEEE Standards process the 
scribe "correcting" Gotteibam's description with a bracteted "actually, ANSI" Standards 
process). While the minutes do not suggest that ariyone on the Steering Committee had any 
doubts about using the IEEE Standards process, Gottedem recalls a few familiar with it 
(Druffd, ChikDfsky, and perteps someone else) privately recommending against following the 
vdole elaborate process, because the process usually took "too long" (that is, longer than ariyone 
wanted the work of the Steering Committee to tate). Having had no experience with the IEEE 
process, Gottedem had no idea that "too long" meant "five to seven years" (the normal time for 
devdopng a standard). He was still learning his way around lEEE-CS. 

The recorded discussion of Gottedem's report concerned the "target" of the standards 
SEEPP would develop. Most of that discussion (as the minutes report it) took the form of a four- 
layer chart At the top is "User Programming (100 million people in US)". The next layer 
consists of categories of people: "Applications Generators (0.2 M), "Application Conposition (2 
M)", and "Systems Integrators (2 million)". Below these are 'Infrastructure (1 million)"; and, at 
the bottom, "Academics Foundation Infrastructure (0.01 million)". The discussion concluded 
that the task force should target "the middle layer". This leaves the irrpession that the target is 
to be everyone between User Programming and Academics, more than five million people in the 
US alone, a group at least five times larger than any published estimate of the number of 
"software engineers". So, perti^:s, the Infrastmcture group was v\tot was actually intended 
(Gottedem believes that this chart was Boehm's contribution: "Boehm was always 'chunking' 
[that is, groupng ideas or making distinctions]."** 

The only "action" the Steering Committee took relevant to SEEPP was to assign Barbacd 
and Zweben responsihality for a press release from the 'TF on Ethics and Professional Practices 
through CS/ACM. . . at Hbuse briefing on June 21".* ^ For those already cynical about the lEEE- 
CS and ACM undertaking to mate software engineering a profession, this briefing will seem an 
inp^rtant event Participants not in the Washington area (including both Gottedem and 
Mdford) had expenses paid ty lEEE-CS or ACM. They were brought to a meeting room in the 
House's Raybum Office Building and seated in a row fadng a few reporters.*'' During a 
presentation that lasted only a few minutes, the speaker said something lite "We are worldng on 
ethical issues in conpjting" and pointed to Gottedem and Mdford They had no opportunity to 
speak or answer questions. Gottedem had never seen the speater bdore— and never saw him 
again Soon thdr part of the briding was over and the co-chairs were on thdr way out of town, 
Gotierbam having no idea v\to had arranged the event or v\^.* ' 

3.7 Defining the worldng groups 

56 



On June 11 (ten days before the briefing), the task force held its second scheduled 
meeting. The host was Michael McFariand, then a professor of computer science at Boston 
College.'^^ The location was a local monasbeay. Qf the eight membens of the task force, six were 
pliysically present— with a seventh (Wdsbard) present by conference call. Only Barber could 
not attend even by speater phone. The first half of the meeting consisted of a sorting out of 
research tasks: There was a need for an online library to hold codes of ethics (IEEE, ACM, 
British Corrpjter Society, Australian Corrpjter Society, and so on, including several European 
codes), libliographies, course syllali on conpjter ethics, conference programs, case studies, and 
so on McFariand would find a pece on casuistry to include. A graduate student "from 
somev\tere" would manage the library. We never again hear of this library. 

There followed a discussion of how to circulate the (yet to be prepared) Call for 
PartidpatiorL The first venues discussed were all list servers or dectrordc bulletin boards, with 
p^:er publications (Communications of the ACM, SIGCAS, and so on) considered next. Melfond 
(again) undertook to prepare a "general boilerplate" Call and circulate it to the working group 
chairs. 

The eight working groups were tentatively set up, that is, a chair (drawn from the task 
force) was named for each. McFariand took on Institutional Support; Gotterbam, Professional 
Competence; Weisband and Barber, Intellectual Property; Little, Professional Relations; 
Sullivan, Privacy: Miller, Reliability and Safety; Melford, Security; and Weisband, Social 
Justice}^ 

We might mate three observations concerning these working groups . The first is that 
their titles (or "problems") have changed a hat since May. "Institutional support", "professional 
rdations", and "sodal justice" have been added; "duties to society" and "ethical tools" have 
disappeared Perii^Ds "sodal justice" is a mere synorym for "duties to sodety", but "ethical 
tools" does not seem shorthand for "institutional support" or "professional rdations" (or ariy 
obvious comtanation of them) . 

The second observation is that understanding the architecture of this list of "problems" 
(or the one it replaces) is difficult The list does not seem exhaustive. Some common issues of 
software engineering ethics, such as conflict of interest or tmth in advocating a design option, do 
not seem to fit snugly under ariy of the dght categories. The list also seems not to consist of 
mutually exclusive categories. Some issues, such as protecting information or protecting end- 
users from harm, seem to fit under two or more of the dght categories (say, s^ety and social 
justice). The looseness of the architecture seems to have been noticed Half tte meeting's 
minutes consist of a "discussion of distinguishing content". So, for exanple, "Professional 
Conpetence" is analyzed as "avoid generalization of expertise, teep current, teep staff current, 
tmth about skill, what should be produced, ^Dpropriate knowledge base". 'Vnvacy" is 
distinguished from "Security" because privacy is 'TSTrghtline shows. Monitoring (worl^ace, 
everyv\tere), data aggregation, data valence— digital persona, misuse of data" vMle security is 
"illegal stuff, data integrity, tr^ doors, system administrator responsibility, malidous 
programming, encryption". 

Cleariy, the question of architecture remained This suggests that we might better 
understand tte division of later among working groups by looking at v\to was assigned to chair 
tte group. Since no one now recalls tew this list came ateut, we must try to reconstmct v\tot 
might have h^Dpened Tte only obvious hypothesis is that there is a working group v\tere there 
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is a potential chair already interested in the problem. We can find two sorts of evidence for this 
hypothesis (beyond the lack of obvious architecture). 

The first consists of what we know about the interests of the working- group chairs. For 
some, the evidence is pretty clear. Melford made his living making computer systems secure. His 
interest in security went back to his undergraduate days.^° GotberiDam (as he made clear to 
Ba±acci) thought of ethics as a way of hdpng to assure professional con^Detence. McFariand 
had published two papers on conpjter ethics, each with a final section on stmctuiing the 
institutions in which conpjter professionals work to help them do the right thing.^ ' Long active 
in the Institute for Certification of Conpjter Professionals (ICCP), Littie was interested in 
relations among professionals (v\Mch she understood as primarily professional organization)." 
Miller had published a half dozen articles (and had given a larger number of p^:ers published in 
transactions) on testing and reliability in the four years just before joining SEEPP.^ ^ Sullivan' s 
interest in privacy had been devdopng for several years and would lead him, only three years 
later, to leave CEI to join Price Wateriiouse's new consulting group concerned with conpliance 
with U.S. and international privacy and data protection regulations.^* Wdsband would have 
brought a concern for social justice with her from the Committee on Public Policy.^ ^ 

Barber appears to be the chief exception. He was recruited because he specialized in 
intellectual property; yet he is not chair of the working group on intellectual property; Suzanne 
Weisband is. Weisband was first named as a possible participant in the organizing meeting on 
January 29 without any subject being mentioned. But she had recently published two (short) 
papers on software piracy. Periiaps she reminded Melford of that v\ten he contacted her in 
February to invite her to SEEPF s April meeting. She is listed ahead of Barber under Intellectual 
Property, out of alphabetical order, the normal sign of serving as chair Neither Barber' s interest 
nor legal credential was enough to get him his own chair Apparentiy, Weisband got the chair 
because she outranked him (or because he was absent); Barber had to settle for vice chair Thus 
Barber is one of those exceptions that, vMle not necessarily proving the rule, at least does not 
disprove it 

The working group chairs are, admittedly, knov\dedgeable about the problems assigned 
them as well as interested But their knov\dedge does not explain the list Knov\dedge (or 
conpetence) would explain why they were ^pointed as chairs once the list had been drawn up 
but something else must explain the list On tte one hand, knov\dedge did not guarantee that one 
would be the chair Barber doubtiess knew more about intellectual property than Weisband and 
she had another chairmanship (Social Justice). She nonetheless took the chair of Intellectual 
Property, leaving Barber to be vice chair On the other hand, the working-group chairs doubtiess 
knew much about marry problems not on the list such as continuing education or enforcement of 
standards. They must also have thought marry other problems inp)itant enough for SEEPP to 
consider) they had, after all, eariier produced a somewhat different list of problems for the 
working groups. But if no one expr^sed an interest in some of the original protiems, those 
problems would dis^Dpear from the list 

The second sort of evidence for the hypothesis that the list of groups mirrors the interests 
of participants rather than ariy pian for a code of ethics is in the Call for Participation The Call 
(in all published versions) speaks of "working groups. . .being formed to address specific areas of 
concern" (my italics). Though eight are then identified, the Call adds, "Should additional subject 
areas be identified, additional working groups may be established." 
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3.8 The Call goes out 

On August 24, Melfond faxed Gotterbam a draft of the Call for Participation. A week 
later, Gotterbam sent all working group leaders the draft asking for comments. Having received 
almost no comments by the end of October, Gotterbam made a few changes and sent out the 
revised draft for "final" comment by November 5, 1994. As soon as the deadline for comment 
had passed, he sent out the announcement to all the publications previously identified as 
appropriate venues for the Call. The Call was a substantial document, four pages single-spaced 
(with a two-page application form appended). While the official Call did not go out until 
November, Melford seems to have begun sending out (short) unofficial versions earlier (at least 
as early as June)— without telling Gotterbam.^^ 

The Call (November 5) begins "Dear Corrpiter Professional". It had six main divisions 
(as well as an untitled introductory paragi^li explaining the larger lEEE-CS/ACM undertaking). 
The main divisions are: Scope, Purpose, Organization, Participation, Internet Access, 
Conqietion, and Thank You. Each of these main divisions is numbered, beginning with "1.0" for 
Scope and ending with "6.0" for Thank You. Most divisions are quite short (a single sentence for 
all but Scope and Organization). But Organization, with eight subdivisions, covers two-and-half 
pages. 

The Scope 1.0 states that the task force would "document generally accepted principles 
for identifying and resolving ethical conflicts" in software engineering— suggesting a 
(descriptive) survey rather than a (prescriptive) codification. The Scope then provides a list of 
stateholders (persons or groups v\tom the software engineer might Iwe special responsihalities 
or obligations to: "peers and laypersons, enployer, customerts), the profession, and 
society/humanity". But the Scope also includes in tte task force' s work "consideration. . . [of] the 
obligaitions and responsitalities of these various entities towards the Software Engineer^' 
(something the Purpose statement immediately following omits). This reference to obligations of 
those v\to are not software engineers suggests a document (lite the American Medical 
Association's 1847 code of ethics) that states reciprocal obligations between an occupation and 
other stakeholders ("rights and responsibilities"), not— like a typical professional code— a simple 
statement of the profession's obligations. We never again hear of the obligations of others to 
software engineers. 

Scope 1.1 adds that the task force recognizes that the profession "transcends national 
boundaries". Any standards the task force developed should "be as reflective of the global 
computing community's wisdom as can be reasonably achieved." The standard will state what is 
generally accepted or, where no one standard is generally accepted, "various recommended 
practices and guidelines". 

Organization 3.0 describes the eight working groups in more detail than the June minutes, 
but in much the same terms— except that Barber is now explicitly designated as vice chair of the 
working group on intellectual property (with Weisband as chair). 

Participation, the first subsection under Organization, contains several surprises. 3.1 
declares participation "open to all individuals who are directly or materially affected or 
interested in" any issue within the Scope of the working group. "Members of the international 
computing community" are "particularly encouraged to participate". Essentially, anyone who 
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wants to participate can, presumably even a gaucho on the Argentine plains or an Imam in the 
holy city of Qom. Participation 3.1.1 adds that individuals may participate in as many working 
groups as they desire. 3.1.2 allows organizations to send representatives but warns that no 
organization will have a "veto". After all these inviting words, 3.1.3— all in caps— comes as a 
surprise: "PLEASE COMPLETE THE APPLICATION AT THE END OF THIS DOCUMENT 
AND E-MAIL IT TO SEEPP-CFP© C0MPUTER.ORG, BEFORE 5-NOVEMBER-1994. We 
are organizing the working groups on 12 November 1994." The November 12 deadline— at 
most a week from the date on which the Call was issued— is reasonable if, but only if, the 
expectation was that great numbers of potential participants were ready to apply and most of 
tiiem would read the Call soon after it was sent out. If, however, filling out the form was 
demanding enough to be put off for a time for other things, or if many who might read the 
message would wait till it had been printed and distributed, or if the pool of potential participants 
was in fact small, any deadline, but especially one so tight, seems to be a mistake. It is a good 
sign, then, that when Gotterbam and Melford met again, along with Sullivan, on November 11, 
at a computer ethics conference in Washington, DC, they already had two dozen or so 
applications to look at. 

Later versions of the Call, such as that printed in the December 1994 issue of Computers 
and Society, never again contained a deadline for application. Earlier versions of the Call— for 
example, the preliminary October version that Gotterbam had sent out to some lists in 
October^^— also contained no deadline. The November 5 deadline thus seems to have been a 
(tenpjiary) atteiig* to speed the pKx:ess rather than a device to teep the nmnber of participants 
down— arid it seems to have worted 

3.9 A good report 

A few days after the November meeting, Gotterbam sent the list of those responding to 
the Call to all the working group leaders, asking them to identify ariyone interested in their 
working group, organize mailing lists for their group, and get to work. By then, the ^plicant 
pool was over thirty (with marry indicating they wanted to participate in two or more of the 
working groups). 

So, v\ten, on November 18, the Steering Committee had to report to the lEEE-CS Board 
of Governors on its activities for the year, it could describe SEEPF s achievements with at least 
as much pride as those of the other two task forces: 

Meetings 

• April 30, 1994, CS Headquarters 

• June 11, 1994, Boston College 

• November 11, 1994, Ethics in the ComputerAge Conference 
Working groups 

• Institutional support 

• Intellectual property 

• Professional competence 

• Professional relationships 

• Privacy 

• Reliability and safety 
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• Security 

• Social justice 

Call for participation in wide circulation 

These achievements were apparently substantial enough that in December, Barbacci 
undertook to cover the task force's overhead (a few conference calls and some travel) .^^ The 
pajyment of these expenses seems significant only because the Call mates clear (Finances 3.1.3) 
that most expenses will not be covered: "Participation is voluntary. Each individual is 
responsible for expenses incuned to support higher partidpation. Many institutions provide 
support for their volunteers." 



NOTES 



' Dennis Frailey has BS in mathematics from Notre Dame University (1960) and an MS 

and PhD in corrpjter science from Purdue (1971). He claims to have worted in sofbA/aie 
engineering before there was such a field (that is, since 1962). He worted for Texas Instmments 
and Rafheon while also serving as an adjunct professor at Southern Methodist University. See 
http//engr.smu.edu/-^railey/hao.html (August 28, 2004). Frailey became vice chair when 
Zwebea having become AMC President, became a a mere ex officio member. 

^ While Hodzeman is listed as a member ex officio, that designation seems to be a 

mistate. The "ex officio" are task force chairs. Hodzeman is not a task-force chair (and seems to 
hold no other office that would entitle him to that designation— though he was then a men±)er of 
the lEEE-CS Board of Governors). He can only be Schneidewind' s replacement 

^ John Werth has a BS and MS in Mathematics, Emory University (1962 and 1963) and a 

PhD in Mathematics from University of Washington (1968). He was at this time Senior Lecturer 
and Research Scientist Conpjter Science Department University of Texas, Austin, http 
//www.cs.utexas.edu/usens/j werth (August 28, 2004). 

^ Laurie H Werth Qohn Worth' s spouse), was an eariy SEEPP volunteer. She too taught 

conpjter science at the UT- Austin. Gotta±am\SEEP1994r95, sec. 11. 

^ SeeCh^Dter2.3. 

^ http//sunsetusc.edu/Research_Grouptorry.html (August 28, 2004). I have corrected 

some dates of publication. 

' Fddman declined to be interviewed for this book, claiming to have had nothing to do 

with SEEPP, even though his own haogr^±y lists him as a member of the Joint ACM-IEEE task 
force. See http://vvww.research.ibnicorn/iac/advisory-fddn]aahhril (August 28, 2004). Ch^Dter 
8.6 describes Fddman' s part in writing a 1997 disclaimer that SEEPP was to put in published 
versions of the code stating that the publication of the Code draft (Version 3) did not indicate ariy 
^Dproval of the Steering Committee. Perii^:s this was the extent of Fddman' s participation and, 
from his perspective, not a significant contribution to the code. 
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I have not been aHe to find a written source for these estimates. 
^ An affiliate member of lEEE-CS has vote in the CS but not in its parent IEEE. 

^° http://www.ieee.oig/nMnbenship (August 28, 2004). Since 2001, ABET and CSAB have 
woited together on accreditation, dispatching joint committees. 
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http//www.acnioig/membeiship (August 28, 2004). 



' ^ That is, he did not receive a degree from an ABET-accredited engineering program and 

probably could not be licensed as a P.E. (since he lacks an ^Dpropriate degree). Qr, as Mdfoid 
himself put it, in answer to the question, "Are you an engineer?" (Interview of Mdfoid, 
November 1, 2002): 'TSbtoffidally. I'm not licensed and I don't have a degree. Butmostpeople 
would consider me to be an engineer. I think most of n^^ colleagues view me as such. I certainly 
identify with that side of my fidd, probably rmre than anything dse other than general business. 
I am an engineer in the sense that I detennine how techrDlogy can be ^Dplied in a cohesive and 
conplimentary manner to solve problems." See also his answer to question 1, about his 
education (endnote 15 bdow). 

' ^ Interview of Mdfoid, November 1, 2002. 

' * "I left school to earn a living. I was studying economics. I have some foimal education in 
economics and some in programming. I am fully sdf-educated in systems management as wdl 
as the business side of conpjting operations. I am fully sdf-educated in networking, the 
technical aspects of netwoikn^, as wdl as the ethics. One of rr^^ incentives for leaving school 
was that I wasn't able to get v\tot I was after At the time, there was basically nothing available 
on conpjting security. I originally went in to study dectrical engineering, but found that that 
wasn't quite n^^ forte. I came into confuting in a backward sort of way. I read some issues of 
Scientific American in the late '70s or early '80s. I believe it was the September 1980 issue that 
was devoted to automation in the workplace, and the following issue in October was dedicated to 
software computing. Those two articles were extremely influential on me. They made me think 
about automating the business workplace. During that time, I had taken several courses in 
programming and management of information systems (MIS). I found that I had a knack for it. I 
also took programming classes that were oriented toward business majors, towards accounting 
students. That was at Cal State Northridge. When I left school I decided that I wanted to continue 
my education on my own. So I went and bought a PDDU. Yes, that was the computer Digital 
Equipment Corporation then made, the old deck PDDU, forerunner of the Vax. I mounted an 
early version of UNIX on it, and started to go from there. That led into some consultant work. I 
started my own consulting practice in 1984. I did consulting for 15-16 years." Interview of 
Mdford, November 1, 2002. 

'^ Gotbe±am's vitae also lists (among philosophy publications during this period): "A 
Modd for Software Engineering Ethics" in Lecture Notes in Computer Science: Software 
Engineering Education (Springer Verlag, 1989). Amid this philosophy, are Gotterbam's first 
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publications in computer science: "An Optical Bus Architecture", Technical Report F86-2, 
Allegany College Technical Report Series (1986): and a contribution to pedagogy, A Study Guide 
for Hexadecimal Arithmetic (Harrisburg Area Community College, 1980). 

^^ Gotbeatam could be a "faculty tutoi^' because he was also teaching philosopliy at HACC 
(IntnDduction to Philosopliy and Logic). 

" Thomas J. Ddoughry, "Failure of Colleges to Teach Conpjter Ethics is Called a 
Oversight with Potentially Catastrophic Consequences", Chronicle of Higher Education, 
February 24, 1988. 

' ^ Gottedam later wrote the first encyclopedia article on software engineering ethics for the 

Encyclopedia of Software Engineering (1994), p. 1197-1200. 

' ^ The ACM pays the airfare of a Lecturer for a visit to an ACM professional or student 
ch^Dter. The local organization covers food, hotel, and other local expenses. 

^° Anderson is (and was then) a sociologist at University of Minnesota (PhD., Stanford, 
1970). For an explanation of the code— and a trief history of writing a code much less messy 
than the one described here—, see Ronald E. Anderson, 'The ACM Code of Ethics: History, 
Process, and Inplications", in Chuck Huff and Thomas Finhold, editors. Social Issues in 
Computing: Putting Computing in its Place (McGraw-Hill, Inc.: New York, 1994), pp. 48-62. 

^' The most important of these conferences were: the Computer Science Conference and the 
National Educational Computer Conference. 

^^ After Anderson, the ACM code lists as authors (with the parenthetical affiliations being 
rriy addition): Gerald Engd (University of Connecticut- Stamford, but then on loan to NSF), 
Donald Gotberbam (ETSU), Grace C. Hertlein (California State-Clico), Alex Hoffman (Texas 
Christian University), Bruce Jawer (IBM), Deborah G. Johnson (Rensselaer Polytechnic 
Institute), Doris K. Lidtte (Towson State), Joyce Currie Little (Towson State), Dianne Martin 
(George Washington), Dorm B. Parter (Standards Research Institute, but with an early book on 
conpjter ethics), Judith A. Perrolle (Northeastern University), Richard S. Rosenberg (University 
of British Colurntaa). Note that all but two (that is, 4/5' s— not counting Anderson) are 
academics. Anderson, "ACM Code History", does not explain how these few names were chosen 
from the larger number of those who participated in some way or another in writing the ACM 
code. 

^ ^ Among others v\tom Gotteibam first met at the conference and would later recruit for 
SEEPP was a philosopher at the RCCS Qohn Fodor, v\to had only recently received a PhD. 
from Washington University- St Louis) . 

^^ Donald Gotterbam, 'Two Corrpjter-Rdated Codes", Perspectives on the Professions 19 
(Fall 1999): 5-6 
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^^ TTis p^:er eventually ^Dpearai in the Communications of the ACM (February 1993): 98- 
108. Judith Perrolle also listed as authors. This paper and presentation were Johnson's only part 
in "writing" the ACM code of ethics. Apparently, one can become an author by lending one's 
authority to a text (authorizing it) as well as by helping to write it (authoring it). 
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Gottedam, 'Two Conpjter-Rdated Codes". 

X (n]em3'snairie)givesthedateas'TSrovemberlO'\TTiatseeii]stobeatyp^ 

Ba±acci, email, September 12, 2005. 

Undated Gotle±)am memo beginning "Mario, I ergoyed meeting". (p^:eronly). 

Gotle±)am' s emailed comments on March 24, 2003 draft of this ch^Dber, p. 9. 

Gotberbam, email, April 24, 2003. 

Undated Gotterbam memo beginning "Mario, I enjoyed meeting" (paper only). 



Anderson had never divided work on the ACM code into parts. His group had always 
treated the code as a single indivisible undertaking. Hence, the decision to divide SEEPP into 
working groups does not seem likely to have originated with Gotterbam. 

^^ Gotberbam knew Engd from ACM (see below). Barbacd and Mdford also knew him— 
fromlEEE-CS. 



35 



36 



37 



39 



Gotterbam\ SEEP1994r95\HRST meeting 1-94. 
Gotterbam\SEEPP1994r95\SEEP2A. 
http//vvww.hrook.edii/its^cei/cei_lp.htm (August 28, 2004). 



This was at the fourth "Conference on Computers, Freedom, and Privacy", held at the 
John Marshall Law School, Chicago, March 23-26, 1995.Gotterbam, who had organized the 
panel ("The Licensing of Computer Professionals"), is identified in the panel's abstract as "chair 
of the SIGCAS Task Force on Licensing and Certification of Computing Professions". Barber 
was on the panel (more or less) by accident. Gotterbam had initially asked Lance Rose, a New 
York City attomey specializing in software and online intellectual property. Rose had previously 
spoken on licensing to a software consultants' group in New Jersey. Since Rose was doing other 
things at the conference and felt he did not have much more to say on the panel's subject, he 
suggested one of his associates. Barber, instead. Barber, though new to lawyering Q.D., Yeshiva 
University 1993), seemed a good choice. He had a B.S. in Computer Science and Engineering 
(MIT, 1987). From 1984-1990, he had worked as an in-house developer for a vendor of 
packaged commercial software. He had worked on IBM protocol emulation packages for PCs 
and Unix-based systems. He was exposed to and performed tasks related to almost all phases of 
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the software development lifecycle— module design, implementation, testing, in- house and field 
maintenance, and project management. He also co-wrote and edited a technical book (Lewis, 
Barber, and Siegel, Programming in Java IDL, Wiley 1987). Gotterbam, impressed by what he 
heard (arguments against professionalization), invited Barber to dinner, laid out his plans for 
SEEPP, and invited Barber to join. Interview of Barber, November 14, 2002. 

'^° Gotlie±)am\Hisbory of SE Code\Hisbory expanded, under 4/95 meeting: "partial list of 
attendees. Robert Melfoid, Don Gotbeatem, Steve Ba±er, Joyce Ciraie Little, Patrick Sullivan, 
and Fletcher Buckley and Suzie Weisband on conference caU. [v\tere did I find out about 
ChikDfsky and McFariand?] 
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Interview of BariDer, November 14, 2002. 



*^ There was also a "guest" present, Sam Redwine, a sofbA/aie engineer, at that time 
Assistant to the President and CEO of the Software Productivity Consortium, Hemdon, VA. He 
is now an Adjunct Professor, Inforaiation and Software Engineering, George Mason Urdvensity. 
Highly respected within lEEE-CS, Redwine may have been present sinply because he was in 
town and knew a lot about IEEE procedures. 

" While the minutes give the irrpession that these three axes were the work of SEEPP, 
GotberiDam claims that Bany Boehm suggested them during discussiorL (Emailed comments on 
draft of ch^Dter, Gottedem, March 24, 2003.) Gotteatem's claim may provide a good exanple 
of the unreliatality of memory. Gottertem' s Archive contains an undated document (SEEP1994r 
96, STEER.M1A), ^parenfly the written report Gottertem and Mdford submitted to the 
SteeringCommitteeinadvanceof the May meeting (the conpjter file bears the date of May 27, 
1994, one day be/ore the meeting). This document explicitly discusses the "three axes". So, if the 
file date is right, then the axes are (one of) Gotterbam' s contributions, not Boehm' s. 
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Gotterbam email to Davis (March 24, 2003). 



*^ As Gottertem (March 24, 2003) recalls events, Zweben was to help draft the release 
because he had raised several otgections to the version BariDacd had presented at the Steering 
Committee meeting. The minutes give no indication of this. GotberiDam also recalls BariDacd 
saying that he was still seeking funding to help support SEEPFs work. The minutes mate no 
mention of that either. 

* ^ GotberiDam, v\to already had an airiine tictet to Boston to attend a conference, only hailed 
ACM for $60 to break his journey in DC and $22 for cab fare to and from Washington National. 
GotteriBm Archive\SEEP1994r96\ACM expenses. 

* ' GotberiDam (March 24, 2003) . Gottertem thinks Mdford knew more about the event than 
he did GotteriDam (June 5, 2003, comments on Ch, 2). 
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^^ McFariand has BA. in Physics from Cornell Univensity (1969); M.A. and PhD. in 
Electrical Engineering from CMU (1975). He joined the Jesuits in 1975, and was ordained in 
1984. He worted as a consultant at AT&T' s Bdl Labs in Murray HU, New Jersey, for two years 
(before going to Boston College). He is now President of the College of the Holy Cross, 
Worcester, Massachusetts. His best-known p^:er in ethics then was: "The Public Health, Safety, 
and Welfare An Analysis of the Social Respjnsilility of Engineers", IEEE Technology and 
Society Magazine 5 (December 1986): 18-26, already reprinted in Deborah G. Johnson, Ethical 
Issues in Engineering (Prentice-Hall: Englewood Cliffs, New Jersey, 1991), pp, 159-174. 

* ^ This assignment does not ^Dpear in the official minutes Mdford prepared (Gotteri3am/94r 
95 misc/Boston 6-94), only in Gottertem's 1999 reconstmction of the preceding six years of 
work (addressed to "Leonard" Tripp). Mdford' s minutes merdy conclude with the words 
"Prdiminary assignment of working group chairs" (suggesting that matters may have been a hat 
less settled). Mdford' s minutes also omit Institutional Support altogether, defining Professional 
Rdations to include it— "P-P (support for whistle blowers). P-org, P-individual, P-sodety, P- 
dectrordc community, obligation to foster responsible behavior in the non-professional". It is, 
however, easy to see how Institutional Support might have been carved out of this collection of 
topes. 
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Interview of Mdford, November 1, 2002. 



^' Mchad C. McFariand, "Urgency of dhical standards intensifies in corrpjter 
community". Computer (March 1990): 77-81; and Michael C. McFariand, "Ethics and the safety 
of computer systems", Computer (February 1991): 72-75. These two papers appear in the 
"Standards" section of the magazine, with Fletcher J. Buckley listed as "Editor"; one of 
Melford's papers is cited in the second of McFariand' s. (McFariand was one of Melford's 
recruits.) 
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Interview of Little, June 1 1, 2003. 

See his curriculum vita: htlp//www.uis.edu/Hi]illeryiffiitlihtml (June 28, 2004).. 

Interview of Sullivan, November 10, 2002. 



Suzanne P. Weisband, Associate Professor of Management Information Systems, School 
of Management, University of Arizona. B.A. in Organizational Psychology (San Diego State 
University, 1979); Ph.D. in Social and Decision Sciences and Policy Analysis (Carnegie Mellon 
University, 1989). She is not a programmer but an expert on the "human factors" side of 
computing, http://www.bpa.arizona.edu/~mis/faculty/sweisband.shtml (August 28, 2004). 

^^ S.P. Wdsband and S.E. Goodman, 'International Software Piracy", IEEE Computer 
(Nov. 1992): 87-90; and S.P. Weisband and S.E. Goodman, "Subduing Software Piracy", 
Technology Review (Sept./Oct. 1993): 30-33. 
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^^ Gottedem \by yeaA1993-4\Esla]iishing the CFP (November 5 vension). In an October 
11, 1994 email, Jon Fineman (Gotterbam Arichive\SEEP1994-96\HELPOFR) says it was out in 
IEEE Computer: "Sony to hear the world is giving you a hard time. I am confused though, what 
I was responding to looked like a call for participation that was advertised in the IEEE Computer 
magazine. That's what generated the note, since I did not want to miss the boat. Do you need any 
help getting things organized." Bumstein's (paper) file includes an even earlier version of the 
Call, a "Press Release from Melford" dated June 14, 1994. Gotterbam was doing something 
similar. See Interview with Rogerson, February 24, 2003 (quoted below). 

^^ See, for exanqie. Interview with Rogenson, Febmary 24, 2003: "Qn 19 October 1994, 1 
received a broadcast email [of the Call for Participants] from Don Gotbedem (sent through the 
Conpjler Ethics Institute list to v\Mch I belonged). I'll give you a copy. I sent in a filled out 
form the next day." I never got the promised copy. 

^ ^ The only evidence (in the archives) that Bartaxi in fact did obtain a budget for SEEPP is 
a request from Gotbedem in a letter (Febmary 21, 1996) addressed to Curtis Harris at ACM 
requesting reimbuisement for expenses of a meeting attendance at v\Mch had been authorized by 
Dennis Frailey. Gotterbam\SEEPP1006-97\SEPBIL. 
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Chapter 4: Failing— By the Bocd^ 1995 

straight man: "How's your wife?" 
Comedian: "Compared to what?" 



4.1 The Volunteers 

On January 1, 1995, SEEPP still had almost eleven months to complete its work. If it 
worked at the speed Anderson's committee had, it could easily hand the Joint Steering 
Committee the document promised by the date promised in the schedule drawn up the January 
before. SEEPP also seemed to have the resources to complete the work on time. The Call for 
Participation had brought in at least thirty volunteers.^ Those, comtaned with the seven members 
of the task force, amounted to four times as many volunteens as Andenson had had (or, at least, 
officially recognized in the published code). And, as a group, the volunteers seemed as 
inp:essive in their credentials and as serious as Anderson' s— and a good deal more varied 

Qf the 29 v\to had filled out the ^plication, only 17 were academics (and three of these 
were graduate students).^ The remaining 12 were a mix of independent consultants, (high 
ranking) errqioyees of large corporations, senior officers of smaller sofbA^are conpardes, and a 
few miscellaneous enough to list individually. One was a full-time enployee of a government 
latoratoiy conqieting a graduate degree at the same time. (One of the academics was also 
errqioyed in a government laboratory vMle on leave for the year) There was one philosopher 
(Fodor), one lawyer (from a m^or DC law firm), one business ethidst (Ernest Kallman, Berifley 
College, an ACM member), and even one "retiree". Fourteen volunteers were members of both 
lEEE-CS and ACM. Four were members of lEEE-CS only; two, of ACM only; and the 
remainder who answered the question (seven), of neither. (Two of the 29 ignored the questiorL)^ 

There was also considerable geogr^±iical diversity. The American addresses range from 
Louisiana to Minnesota, from Alaska to Florida, from Massachusetts to California Tennessee, 
with two (not counting Gotterbam), seems overrepresented. (The only other locales with two 
volunteers are: California, Texas, and Washington, DC— counting its Virginia suburbs.) Three of 
the 29 volunteers were British (English, Scot, or Welsh), two Irish, one Egyptian, and one 
Canadian (that is, nationals of the country and resident there). The diversity runs a bit deeper 
than the addresses suggest. So, for example, one of the British volunteers (Narayana Jayaram), 
though long resident in Scotland and England, begins his description of himself as "hailing from 
India" (where he had been bom, raised, and received his first degree in engineering). Perhaps the 
British would count him as an Indian (though he was then Chair of the lEEE-CS Chapter in the 
United Kingdom). There is similar hidden diversity in those counted as Americans. One, for 
example, describes himself this way (and so might offer more of an international perspective 
than the simple description "American" suggests): "I grew up in a developing country (the 
Philippines) and set up a computer science program under the mathematics department in my 
alma mater (Ateneo de Manila University) back in 1981. I have gone to school both in France 
(University of Paris VI) and here in the US (Johns Hopkins University) so I have a unique 
perspective." 
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Most give their reasons for volunteering, along with their qualifications, in response to 
the application's question about "interests". Their reasons for volunteering vary a good deal but 
generally combine experience of software engineering with a commitment to certain standards. 
So, for example, one of the graduate students (Florida Atlantic University) explains: 

I am currently a Ph.D. candidate in Computer Science specializing in software 
measurement and software quality. Reliability and Safety are important quality factors. I 
also have personally studied the Challenger disaster in depth from the perspective of 
ethical issues. I have about 20 years of software engineering experience in industry 
(military systems and health care data processing). 

Some of the applicants echo specific worries about competence described in Chapter 2. So, for 
example, one employee of a large company (in Missouri) explains: 

My interest is in the furtherance of SW Engineering as a professional activity. My 
observation is that ANYONE and EVERYONE seems to believe they can develop SW 
applications. Many of these follow no consistent process or provide any supporting 
products to aid in maintaining these applications. This gives legitimate SW professionals 
a bad name. I believe that ethical standards may provide an approach to solving this 
problem. I have 20 years' experience in developing real-time applications for visual 
simulation applications. I have dealt with a number of these semi-SW professionals and 
believe that this experience will be useful to the ethical standards effort. 

For those applying from outside the United States, the reasons offered seem much the same. 
Here, for example, is the explanation offered by the one Egyptian (Amr El-Kadi, about whom we 
shall hear more later): 

I deal with the education of future SEs and I believe that it is of great importance to teach 
them RIGHT early on. I used to teach Doctoral level courses back in the states and many 
of my students were part timers working for big organizations. Many of them did not 
believe in SE and were still relying on "ad- hoc" techniques not only in civil applications, 
but in mission critical applications as well! I also do private consultation for industry. So, 
I see both ends: academic and practice. Enforcing acceptable ethical/professional 
standards on SEs I feel is part of my duty as a scholar and a practicing SE. 

As a group, the volunteers seem to have a strong commitment to SEEPP's work. 

4.2 "Documenting" 

All this suggested that SEEPP would soon complete its work as successfully as 
Anderson's committee had. Against this hopeful reading must be set at least two negative signs. 
The first was that the working groups, though now organizing, still lacked the "Operation Guide" 
that the IEEE required for developing technical standards. That is, they lacked guidance 
concerning how to proceed. Since the Call's 3.3 declared, "The conduct of each working group 
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shall follow the same written procedures as govern internationally recognized IEEE Standards 
Activities", the working groups could not (officially) begin work until they had the Guide to 
follow. Melford was working on the Guide. He would have to complete it much faster than he 
had the Call— or SEEPP would certainly miss the scheduled November date for delivery of its 
"product". 

The second negative sign concerned what was to be delivered. The November 1994 
meeting of the Joint Steering Committee revealed some confusion (or, at least an unresolved 
difference of opinion) about that. Some on the committee wanted a "standard practices 
document", that is, a document that would consist of relatively specific directives: "When you 
are faced with this particular situation, this is the technical approach you should take." 
(Standards documents can be dozens, even hundreds, of pages long.) Others wanted a short 
general document (a conventional code of ethics, a few pages at most).'^ This confusion was not 
new. It was already present on January 29, 1994 v\ten SEEPP was named Adding the "PF' for 
"and Professional Practice" had suggested something more than a code of ethics without defining 
v\tot that "something more" might be (and, indeed, perteps suggesting no more than that the 
code was to guide professional practice). The same confusion about what to deliver seems 
present in the Call. The general Scope statement 1.0 spoke only of "accepted principles for 
identifying and resolving ethical conflicts" (presumably, a conventional code of ethics) but the 
Global Application section 1.1 concluded with what sounds much more specific— "these 
standards shall also document various recommended practices and guidelines when no clear 
consensus can be established." "Practices and guidelines" certainly sounds like "this is the 
technical approach you should take". 

Related to this confusion about specificity is another: what does it mean to "document" a 
practice? On one interpretation, documenting might be a descriptive undertaking, something 
requiring large surveys or other detailed investigation of what people actually do, say, and think 
as they work on software (the sort of survey that the body of knowledge task force was just then 
undertaking). A few of the applicants seem to have understood "document" in this way, 
mentioning their own empirical research in their description of "interests". So, for example, 
Kallman points out that he is "currently performing empirical research [on privacy] with Jeff 
Smith at Georgetown". Another academic (from Utah) does much the same: "I have been 
conducting research into ethics attitudes and practices among information systems professionals 
for about five years." 

Most applicants, however, say nothing to suggest that they need look any further than 
their own experience to "document" (or at least set down) appropriate standards. So, for 
example, an AT&T vice-president (in New Jersey) simply states his "interests" this way: 

I have managed software projects for twenty- five years and written and spoken on 
software ethics and project management as well as network management. I am interested 
in how we may certify software managers, global development software, software safety 
and software stability. 

Most of the academics presented themselves in much the same way, for example: 
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As Chair of the Electrical and Computer Engineering Department at the University of 
Texas at Austin, I have a considerable interest in this topic. Further, I have implemented 
an undergraduate and graduate program in SE over the past two years and we are 
presently implementing an executive M.S. program in SE, for industry. 

Another Texan (a grad student) also offers his interest and experience as his qualifications for the 
work of "documenting": 

I have been involved in computer security since 1986 when I was assigned to the US Air 
Force's Computer Security Office in San Antonio, TX. I served there as the chief of the 
R&D Branch and as chief of the Network Security Branch. I was then assigned to the 
USAF Academy where I taught in the Computer Science Department. I am currently a 
Ph.D. candidate at Texas A&M University working in the area of computer security. I 
have been the author of several papers on computer security as well as a recent paper on 
ethics. I am currently working on a textbook on computer security with a tentative 
completion date of 15 Jan 95. 

4.3 Another Plan 

About the time this Texan was supposed to deliver his textbook to the publisher, the first 
of the two negative signs disappeared. Melford delivered a draft of the operating guide to 
Gotterbam. Gotterbam sent back a few suggestions for improvement and then emailed the guide 
to his own working group (Professional Competence) on February 22.^ The email tates the forai 
of a letter beginning with the date followed by 'Dear SEEPP Volunteer". After thanking the 
volunteens for their interest, Gottedem admits that "[the] work of the task force has been slow to 
start due to some of our unfamiliarity with this process". After ^x)logizing "for the delay", 
Gotterbam tates a paragi^±i to describe how the working group fits into SEEPF s work and that 
of the Joint Steering Committee's two other task forces. Part of the description justifies the 
division of the task force into working groups as an instance of "good corrpjter problem solving 
technique" (divide the task into several si±itasks that can be distributed so that no one has a task 
too large to handle). Gotterbam then identifies a "problem that has caused some of the delay", 
that is, resolving "the question of how to mange and organize the working group process", and 
(at last) announces, "I have a plan." 

The plan has two parts. The first, briefly described, is sinqiy a "small email list" 
(ProfConqxaErSU-easttermstedu, a "manual listserv"). The list was to allow each member of 
the Professional Con^Detence working group to communicate with the rest of the group without 
revealing the writer^ s individual email address. Located on a server at East Tennessee State, the 
list would not resend automatically (as a tme listserv would). Gotterbam would "moderate" it, 
that is, pass on ariy messages properly directed to the list after screening out "spam" (junk mail) 
and "other irrelevant activities". Any mailings to the list address would go only to the list 
Gotterbam also wanted men±)ers of the working group willing to yield a little of their privacy to 
be able to communicate with each other without going through him He therefore promised to 
circulate a list of all current members of the working group. Aryone v\to did not want to be on 
that second list could notify him "within two weeks". He would send out the preliminary list on 
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March 5, asking for corrections. He also promised that this second list "will not be circulated to 
any other organization nor will it be made available by me to any other group."^ 

The second part of Gotberbam's plan was more substantive, a "general outline for the 
devdopment of our standards of professional con^Detence". This outline, "written in Jdlo", had 
three steps: 1) gather information, 2) analyze it, and 3) synthesize it in a "statement of scope". 
The information would tate the form of digests of "other profession' s standards of practi ce" (my 
italics). Each member of the working group was to send to the "LIST" the name and address of 
any organization known to have standards of professional practice, as well as an indication of 
willingness to get copies of the standards (preferably in electronic form) for the working group 
and willingness to write a "short abstract" of that standard "indicating the scope of application of 
the standard, means they use to update it, how practitioners are educated about that standard, and 
the methods of standards enforcement, if any." Given this information, Gotterbam suggests, 
"[we] should be able to abstract a model of professional practices for our use." This "model" is, 
apparently, the "synthesis". It must then be put into in a "Scope" (a statement of "what it is we 
think we are doing") and a "structure" in which the working group would "organize our 
suggestions and conclusions." Once the model is ready, it should be possible to "subdivide the 
problem" and ask for volunteers to write rough drafts of the sections of the document (with all 
drafts circulated to all members of the working group, an "electronic meeting"). 

There are three features of the plan worth noting now. The first is that Gotterbam has 
switched from talk of "professional competence" to "professional practice". Gotterbam has, it 
seems, invited his working group to do what SEEPP (as a whole) was supposed to do. Unable to 
"divided and conquer", he was now trying a more holistic approach. Second, the holistic 
approach was to be temporary. Once the working group had a "model" to work with, it (not 
SEEPP) would divide into several drafting committees (one for each section of the code). Third, 
Gotterbam continues to be a "hands-off" manager. He is still trying to delegate the work of 
drafting to others. 

Following this "plan" are ten single-spaced pages, the long-promised "Guide to 
Operations". Divided into a page-long table of contents and five numbered sections, beginning 
with "Overview" and ending with "Style", the Guide is a document of imposing detail. The 
details provide evidence that Melford had leamed from the advice the experts had given him. For 
example, the Overview begins by observing that the "lEEE-CS/ACM standards for software 
engineering ethical and professional practices... are not being formulated under the auspices of a 
formal IEEE Standards Project Autirorization Request (commonly known as a 'PAR')." The 
standards need only be "developed in accordance with appropriate IEEE and Computer Society 
Standard's Policies and Procedures." (Italics mine.) The IEEE Standards process was not to be a 
straight) acket. SEEPP could have the advantages of the IEEE Standards process without the 
disadvantages.' 

The IEEE process nonethdess wdghs heavily on the document Six of the ten items in 
"Rderences" (section 2) are IEEE publications concerned with IEEE Standards. (The remaining 
four are generic: Robert's Rules of Order, The Chicago Manual of Style, a Handbook on 
Nonsexist Writing, and Webster's New Collegiate Dictionary.) Section 3 (immediately following 
the references) consists of "definitions". Subsections 3.1-3.3 are concemed with defining "IEEE 
standards", distinguishing between "standards" (with a small "s"), "Standards" (with a capital 
"S"), "recommended practices" (marked by a "should" rather than the "shall" of a Standard), and 
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"guides" (more than one practice can be recommended). They also relate these distinctions to 
ACM practice. Section 3 concludes with a list of fourteen acronyms (including "WG" for 
"working group"). Section 4, by far the longest (about six and a half pages), sets the procedures 
for working groups (meetings, quorum, voting, the first draft. Scope, outline, appropriate title, 
membership requirements, expiration or revocation of membership, elections of chairs and vice- 
chairs, balloting, and resolution of comments, objections, and negative votes). The Guide's 
procedures are, more or less, the IEEE procedures for writing standards. They are quite detailed. 
Consider, for example, "4.1.4 The first draft": 

After establishing a draft Scope (see clause 4.1.4.1), the WG should outline the important 
issues and sub-topics it thinks the standard should address (see clause 4.1.4.2). The WG 
should also establish the nature of the standards it is to develop (i.e., standard, 
recommended practice, guide, etc., see 4.1.4.3). Although it does not have to be included 
in the text of the standard, the WG should clearly and concisely define the purpose of the 
document. This generally describes "why" the document is being developed. For 
example: 

"Purpose: Full- range current limiting fuses are not currently covered by 
standards. In fulfilling this need, the working group will also define and 
recommend an overall action plan to clarify and improve industry understanding 
for all types of fuses." 

The WG Chairperson should then identify an individual to author an initial draft. The 
author should be permitted to prepare the draft with or without additional input or 
assistance from any other WG members, at his or her discretion. The consensus of the 
WG membership should then be evaluated to determine if the complete draft can 
subsequently serve as the foundation for an iterative process of refinement.^ 

4.4 Too many meetings 

Since this memo went out on Febmaiy 22 (with that date), Gotbeibam and Mdfoid had 
substantial progress to report to the Steering Commitbee v\ten five days later, it met in Nashville 
(v\teie the ACM was also meeting). The working groups had been set up. The Guide was (more 
or less) conplete and distributed At least some of the working groups had begun work. There 
was still plenty of time to conplete a draft of the code of ethics before the November deadline. 
No surprise, then, that, the enphasis of the Steering CommittBe's half-day meeting was not 
SEEPP but (again) the Body of Knov\dedge Task Force (now officially so called). What is 
surprising is that, after the three task forces had reported, the Steering CommittBe moved into an 
hour-long executive session— an executive session that excluded the ex officios. Though we lack 
minutes, we know something of v\tot h^Dpened 

Late in 1994, Pat Douglas, chair of the Body of Knov\dedge Task Force, had presented 
the Joint Steering CommittBe with a rough draft of her task force' s initial report, the plan for a 
survey of practitioners to see v\tot knov\dedge they thought necessary to be a con^Detent software 
engineer. The Steering Conrnttee had to review the plan before the survey could begin Some 
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members of the Committee found the plan potentially controversial enough that the chair 
scheduled the executive session after the plenary meeting. Douglas thought the executive 
session, though unusual was understandable. Her task force was to decide what should be taught 
to would-be software engineers and (in effect) who should teach it. For academics, that meant 
student enrollments (jobs) for some and loss of enrollments (and perhaps loss of jobs) for others. 
What Douglas did not find so easy to understand is what happened during the executive session. 
From questions asked of her later, she concluded that, in her absence, the Committee had 
assumed that the survey would be 60 pages long, a survey so detailed that nobody was likely to 
fill it out. Somehow her presentation the hour before, and the questions that followed, had not 
prevented the Committee from confusing her written report (seventy pages long) with the survey 
it discussed. Secrecy has a price, a price SEEPP never had to pay.^ 

On March 25, 1995, Gotbedem, Mdfoid, Ba±er, and Miller met in Washington, DC. 
They conqieted the Operations Guide and also started on the task force' s "Scope" (v\Mch they 
hoped would serve as a model for the Scope each working group would also have to write). 
Gotierbam and Mdford also agreed to meet again, in April, during the meeting of the SEI's 
Faculty Development Workshop in New Orleans. At that meeting, they did no SEEPP work but 
agreed to meet again at the National Education Corrpjting Conference (NECC) injure. 

But once home, Gotierbam changed his mind Of the twenty-two months SEEPP once 
had to write the code of ethics, it now had only six, much less time than Anderson' s commitiee 
had needed to write the ACM code. At this rate, SEEPP could not meet its November deadline. 
Eariy in June, Gotierbam wrote Mdford to explain v\tot he had decided' ° The letter began (after 
the sinqie salutation "Bob") ty announcing that Gotierbam had cancdled the June meeting 
because there would have been only four in attendance (Little and Barber in addition to himsdf 
and Mdford). Gotierbam then turried to v\tot was really bothering him ("a m^or problem"): 
"We are just plodding along and have not given adequate direction, advocacy, or leadership ty 
exanple to tte group." What Gotierbam meant, he said vvas that "We schedule meetings but tte 
preparation is not conqiete. . . and we leave with tasks to work on between meetings [that] are not 
corrqieted ty the next meeting. With the exception of the draft CEP and the draft guide to 
operations, work seems to be done ONLY at tte meetings." To support this claim, Gotierbam 
summarized tte m^or events in SEEPF s history, taking almost a single-spaced page, beginning 
with tte meeting of April 30, 1994. He then retuimed to his main point: 

We have meetings and articulate great plans but very little h^pens. We have many 
volunteers from Septen±)er-November of 1994 v\to are conplaining [— ] wondering 
v\tea if, we are going to get started Some of ttose v\to originally volunteered for 
working groups have already abandoned ship. I am afraid tte same is h^perdng with tte 
task force itsdf. 

Gotierbam concludes ty asking Mdford to email "tte material we worted up in Washington", 
promising to write a cover letter to tte volunteers "with some directions on tew to get started a 
plea to contact thdr groups, etc."' ' 

A few days after he wrote that letter, Gotterbam emailed a list of the working group's 
members, including mail and e-mail addresses, asking recipients to "check for accuracy" (June 
10, 1995). There were twenty- four names on the list. Two were new. Eight of the originals were 
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gone. Among the first corrections to come in were three from the Illinois Institute of Technology 
(IIT). Behind these corrections lay a sequence of events extending back six months, events that 
offer a foot-soldier's perspective on SEEPP's work. 

4.5 An idea for research 

On a cold but bright Chicago morning early in December 1994, Vivian Weil, Director of 
IIT's Center for the Study of Ethics in the Professions (CSEP), sat at her desk reading a 
photocopy of the three- page Call for Participation printed in Computer and Society. Someone in 
IIT's Department of Computer Science had sent it to her because CSEP, one of the oldest ethics 
centers in the world, was one of the few with a focus on engineering. It was also one of the few 
with an enduring interest in codes of ethics. CSEP has two external functions: 1) to do research 
concerning professional ethics; and 2) to aid the professions by making its knowledge of 
professional ethics, its research, and its teaching available to the professions. From its beginning 
in 1976, CSEP had collected codes of professional ethics more or less systematically. By 1994, it 
had several hundred on file. Those files might be useful to software engineers trying to write a 
new code of ethics. (Recall that one of SEEPP's first plans, never carried out, was for a 
depository of relevant codes.) 

Then CSEP's Senior Research Associate, I had written a half dozen or so articles on 
codes of ethics.^^ I thought a code of ethics was central to organizing an occupation as a 
professron Weil, on the other hand, was less certan She tended to think of codes as a means of 
education in already existing obligations. That morning, though, she was wondering v\tot those 
v\to write codes think they are doing. It might be interesting to find out Here was the 
opportunity, an opportunity for CSEP both to do interesting errprical research and to mate itself 
useful to a new technical profession Weil did not know much about software engineering, 
indeed, until reading the Call, she had, she believes, never heard the term. But after almost 
twenty years doing professional ethics, she no longer worried about starting out ignorant of a 
discipline. What was inpjrtant was having the resources to learn what one needed to know. For 
software engineering, tte resources to learn seemed readily available. IIT's Conpjter Science 
Department taught several courses in software engineering. A phone call had given her the 
names of the two faculty v\to taught the courses. So, Weil decided to put her thoughts on p^:er. 
The result was a concept statement of about 500 words, "a Project on the Creating of Softv\^, 
Professionalism, andResponsihality."'^ 

Over the next few days, Weil phoned people she knew v\to might know something about 
software engineering generally or the joint lEEE-CS/ACM project and repeatedly rewrote the 
concept statement to tate into account v\tot she had learned By the second week of Decen±)er, 
she f dt ready to bring together the people she had identified as interested, locally available, and 
potentially helpful. On December 15, they met Ilene Bumstein (Conpjter Science, IIT, an 
expert in sofbA^ development process); Barry Weiss (a Chicago lawyer interested in liatality 
for software failure); Ullica Segerstrale (Social Sciences, IIT, with an interest in science studies); 
and me (expert on codes).'* What became clear at the meeting was that there was interest in 
doing somdhing related to the concept statement but no agreement on v\tot in particular 
Bumstein seemed to be interested in technical standards; the lawyer, in issues of responsitality; 
and I, in writing a code of ethics; but we eventually agreed to focus on Miller^ s working group 
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on Reliability and Safety. Weil revised the concept statement accordingly. There were several 
more meetings, with Bogdan Korel (a colleague of Bumstein's with an interest in software 
testing and debugging) making the research group six. The three with enough time (Bumstein, 
Weil and I) became "the research group"; the otiier tiiree (Korel Segerstrale, and Weiss) 
became "consultants". 

By the middle of January, Weil thought the concept had developed far enough that she 
asked me to contact Gotterbam, with whom I had shared a stage once or twice, to see whether 
SEEPP might be able to use CSEP's resources and whether CSEP could study SEEPP's work. 
Gotterbam responded enthusiastically, even putting me on the Professional Competence list (as a 
courtesy because he thought my interests closest to his own). I therefore received the long email 
of February 22 that delivered the "plan" and Guide. The day after that email, CSEP submitted a 
proposal to the National Science Foundation (NSF) for a fast-decision Small Grant for 
Exploratory Research. The proposal was fast- tracked because SEEPP's schedule did not allow 
for NSF's normal six-month review. SEEPP was supposed to complete its work before a normal 
review could have determined that IIT's would-be participant- observers deserved support. (By 
February, CSEP had also received Miller's enthusiastic invitation to participate in the Reliability 
and Safety working group.) 

Since the proposal was funded two months later, it is worth noting that it contained some 
significant errors. The first is in the Project Summary. It explicitly uses "SEEPP" as the acronym 
for the Joint Steering Committee. This suggests that IIT's research group had a poor grasp of the 
distinction between Joint Committee, task forces, and working groups. I certainly did. The body 
of the proposal contains other evidence of that. So, for example, the fourth item under 
"outcomes" is: 

Because the Joint Committee has adopted an open process, allowing everyone to read the 
committee debate (on e-mail) and to respond, we hope to participate in that debate as well 
as monitor it, not only asking questions both substantive and procedural (for our benefit) 
but asking or answering questions for the benefit of the important work the Joint 
Committee is engaged in. 

There would be little to object to in this sentence if it had referred to "SEEPP" rather than to the 
"Joint Committee". SEEPP had indeed adopted a (relatively) open process. Anyone in the world 
with an interest could join one of SEEPP's working groups and the deliberations of a working 
group were open to all its members. That was, however, not true of the Joint Committee. Neither 
its membership nor its emails were open to the world; indeed, some of its deliberations were 
closed even to its ex officio members. How many other volunteers were as confused about 
SEEPP's organization as IIT's research group? 

This confusion may explain in part why the IIT volunteers sought to "correct" 
Gotterbam's June mailing list for members of his working group (Professional Competence). 
Gotterbam had not made a mistake. IIT's volunteers (Bumstein, Weil, and I) did not belong on 
that working group's mailing list (as members). We belonged on the mailing list of Miller's 
working group (Reliability and Safety). Even though I was on the Professional Competence 
email list, I did not (technically) belong on the list of members. I had been added to the list as an 
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observer. I too had joined only Miller's working group/^ Four months of silence (Febmary to 
June) had been enough to wipe out all memory of Milla:^ s working group. 

4.6 Out of nov\tere 

Confusion about SEEPFs stmcture, while explaining pait of the reason for "correcting" 
Gotierbam's June list, is probably not the v\tole explanatiorL Underlying the confusion was a 
growing unease (akin to v\tot provoted Gotierbam's "Bob" letter). IIT's research group had 
officially begun monitoring Miller' s working group' s email in April, as soon as it was clear that 
NSF would fund the research. There had been nothing to monitor The first SEEPP email to 
arrive in over two months was Gotterbam' s on June 10. Our research group assumed we had to 
be on the June 10 list of volunteers to receive the emails we were supposed to monitor and that 
we would not have received this email unless we were members of the worldng group in 
question. We had (I think) confused SEEPP with one of its worldng groups. We did not realize 
that we (or, rather, I) had received the members list because, and only because, Gotterbam had 
put me on the Professional Practices list as a courtesy (even though he had not put me on its 
members list). 

Encouraging this misunderstanding was another email that came the same day (June 10, 
1995)— and, indeed, was printed as if it were continuous with the first Again, it was another 
form letter and again I was the only one in the IIT research group to receive it While the emailed 
list had been titied "Volunteers to the professional conpetence working group", this email 
addressed its readers as 'Dear SEEPP Volunteer".' ^ It promised action: 

Sometime back I sert a kick-off letter for our effort The letter, ^Dpended below [email of 
February 22, but dated February 16 and without the Guide], gave a conplete approach for 
the development of our standard. It was probably not a good idea to list all of the tasks at 
once. No one knew v\tere to start To start we need to have some folks junp in and pck 
up particular tasks. I have listed them below. 

There were three "tasks" on the list The first was to develop a "straw man", that is, a model of a 
"professional con^Detence standard" that can be presented to the working group for comment. 
"Do we have a volunteer or two?" The second task was to "examine and summarize other 
professional standards." Attached to the end of the document was a list of exanples of these 
"standards" (with contact information): "BRITISH COMPUTER SOCIETY CODE OF 
PRACTICE, 1 SANFORD STREET SWINDOM, WILTSHIRE SN 1H[; PROFESSIONAL 
STANDARDS— ACCOUNHNG AMERICAN INSTITUTE OF CERTIFIED PUBLIC 
ACCOUNTANTS, INC. COMMERCE CLEARING HOUSE, INC 1997.... [and so on]" Most 
were codes of ethics of professional societies (v\tether titled "code of practice" or "code of 
ethics"). The third of the tasks Gotterbam set was "be original". Aryone with a specific idea 
about v\tot should be a professional practice should "write it up and send it in to fte list". The 
letter concludes, 'This is the first step in item A below ["Gathering information" in the Febmary 
22 email]. I look forward to hearing from you. Don Gotterbam".'' (Since the only SEEPP 
volunteers litely to have this list of codes would be those in his own working group, addressing 
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this email to "Dear SEEPP Volunteer" may have added further to confusion of task force and 
working group.) 

The hoped-for action was slow in coming. The first evidence of it arrived at IIT on 
August 31— from Egypt. Eight pages long (single spaced), Amr El-Kadi's email summarized 
two codes of ethics and also reviewed Microsoft Certification for engineers. This email was not 
only the first evidence of the hoped-for action to arrive at IIT but also the last until early 
November— when suddenly one email after another came in. By then, of course, it must have 
been obvious to everyone that the task force would miss the November deadline. But the emails 
that began to arrive in November suggested something more serious. The first (November 3, 
1995) bore the subject heading "Are We Still Working?" It was directed only to the Professional 
Competence working group: 

Volunteers, 

I haven't received any messages since July. I have sent a couple without response. Are 
we still working?? 

I hope I got your names correct. 
Ed 

For the research group at IIT, this email was full of mysteries. The first was that only 
Weil and I were on the list of recipients. For some reason, Bumstein, the third member of the 
research group, was not. The second mystery was that "Ed" had sent "a couple" of messages 
"since July" without response. No one in IIT's research group had received any of them. Indeed, 
with the exception of El-Kadi's code analysis, Ed's email was the first that IIT's research group 
had received from SEEPP (or anyone involved with it) since June.^^ What had IIT's research 
group missed in July? What had it missed in August, September, and October? Had "Ed" used 
the same email list he was using now (and had IIT' s corrpjter or the ether eaten the mail) or had 
he changed his email strategy? TMid was the identity of this "Ed". His name had not ^Dpeared on 
the list Gotteibam circulated in June. That was odd because the mailing list "Ed" was using (23 
names along with the profconp listserv and the task force's seethics listserv at the Software 
Engineering Institute) was otherwise familiar. Why should we know eveiyone but "Ed"? 

After a meeting during vMch the research group meditated on all this, Weil emailed "Ed" 
(November 14, 1995): 

We have a small NSF giant to study your pnxess of devdopng/foraiulattng 
standards. We have seen no messages since July. Please let us know if we have missed 
ariy. Also please let us see any replies to your message of November 3. 

Vivian Weil and Michael Davis 

A response came the next day 'Tirom Ed Mechler, CCF' (November 15, 1995). Mechler was 
plainly someone not to waste words— or to fail to say v\tot needed to be said 
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Vivian and Michael 

Are you members of this Working Group in SEEPP? 
Is NSF the National Science Foundation? 
Why weren't we informed of your observations? 

So far out of 26 listed members with a possible 2 or 3 cc to other groups, I have received 
3, including yours, that don't belong to the working group and 3 from members 
wondering the same thing I am. I will send you copies when I find out more about you, 
ethics you know. 

How is the weather in Chicago? I have a son who just graduated Penn State as an Arch 
Engr and is working for Turner in Chicago. 

Talk to you later. 

Ed 

Mechler's first question came as a surprise. IIT's research group thought it did 
"belong"— and it had received Mechler's email because it did belong. Of course, as explained 
earlier, the research group thought it belonged because it thought it had joined Gotterbam's 
working group (because it had joined SEEPP, because it had received emails sent to Gotterbam's 
working group, because Gotterbam-co-chair-of-the-task-force and Gotterbam-chair-of-the- 
working- group were hard to keep straight, and because Miller's working group— which it had 
originally signed up for— had been so inactive that it had disappeared from memory). 

The second question (about NSF) told IIT's research group that Mechler was probably 
not an academic. The third, however, added to a worry that Mechler's first email had 
engendered. SEEPP now seemed much less organized than Gotterbam's emails had made it 
seem. IIT's research plan depended on SEEPP's organization, especially on most communication 
going through ETSU's profcomp list and being available to everyone (including the IIT 
participant-observers). It also depended on everyone in our SEEPP working group knowing we 
were monitoring its emails. Clearly, Mechler was now receiving emails about the working group 
that were not going through the ETSU list. That was why Weil had asked him to share with our 
research group the emails he received in response to "Are We Still Working?" Had he shared the 
emails at the time (instead of several years later), the research group would have been even more 
worried. The emails that Mechler received between November 3 and November 15 suggested 
considerable disorder in SEEPP communications. 

The first, sent almost as soon as Mechler's arrived, came from "Manny Norman, Sr. Sys. 
Progmr, LT" (staff, Eastem Michigan University): "I'm still here, but you are the only person I 
ever hear from."^^ El-Kadi responded the next day: "I really don't know v\tot to say except that I 
share your worries: Are we still working, or did someone sinply decide to teraiinate the task 
force without informing the people v\to were willing to work?!"^° Pat Sullivan responded: 
"didn't get previous message— will go back through whaf s come from SEEPP (I haven't 
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received anything since last summer, either). Otherwise, as far as I know, yes, it seems but 
slowly."^^ 

The other two responses were even more worrisome. One, from an assistant professor 
(and Major) at the Air Force Institute of Technology at Wright Paterson, denied membership in 
the working group: "I was hdpng Pat Douglas on the Body of Knov\dedge work Did that get me 
on your list?"^ ^ All Mechler could reply was "your name and address has been on the mailing list 
for the Software Engineering Ethics and Professional Practices, the Professional Conpetence 
working group since June. We just have not heard ariything since July so I sent the message 
below to inquire."^ ^ Mechler sent the same respjnse to Ernest Kallman (November 14) after he 
wondered v\^ Mechler had written him (November 11). Now able to ^Dpreciate the point of 
Mechler^ s question, Kallman wrote back immediately (Noven±)er 14): "I understood that I was 
in the privacy group under the direction of Patrick Sullivan and have communicated this to Don 
Gotterbam I would prefer the privacy group to this area as I fed I have more expertise in it If 
you communicate with Don, fed free to repeat this."^ * 

Mechler now had six volunteers out of six respjnses.^ ^ But the IIT respjnse had brought 
in three volunteers for two addresses (addresses not supposed to be for the Professional 
Conpetence working group at all). Two out of the six responses had denied having ariything to 
do with Professional Con^Detence (even though thdr names were on the members list). That was 
troubling enough. How marry others listed as members had never been members? Were there 
others, lite the IIT research group, v\to (it seemed) should have been on the printed list of 
men±)ers but weren't? This question about the printed list would not have been inpjrtant if the 
ETSU list worted properly. But it did not seem to. Mechler had sent out his original message 
through the list as well as using individual addresses culled from Gottertem' s lists and addresses 
from headers on emails. All respjnses came from individual addresses. 

By Noven±)er 9, Mechler had concluded that the ETSU list was not working— and may 
not have been working since July. He emailed Gotterbam directly: "I have sent two e-mails plus 
ask other volunteers the state of the group since I have not recdved any mail back from the 
group ernail address. I thought I would try to contact you from your original address since no 
activity since July. Please let me know. Gottertem responded on November 14 (without 
acknov\dedging Mechler' s concern that the ETSU list was not working): 'There has been no 
activity because I have not been pushing it I have some concerns with things that are going on 
and I want to be sure your efforts are going to bear fmit bdore I start to push. Thanks for 
hanging in there. I will get back to everybody as soon as I caa"" Two days later, Mechler 
responded: "What are the problems with our project? Can I hdp?"^ ^ Mechler also quoted Wdl' s 
request to be allowed to see "replies" and asted, "Can I honor the request?" The archives contain 
no answer to this email. (Ch^Dter 13.4 will deal with the ethical issue Mechler raised— as wdl as 
several others that devdoped later.) 

4.8 Gotterbam' s Prison 

On Noven±)er 27, 1995, the offidal deadline for conqietion of SEEPFs work, El-Kadi 
emailed again, ^Dparently copying his list from Mechler' s or from Gottertem' s, ndther of v\Mch 
had Mechler^ s address or Gottertem' s. Though the email is largdy addressed to Gotterbam, his 
name ^Dpears only on the "cc". Discontent till now smoldering had burst into flame: 
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I think that Don does owe us all a response this time. As chair of the SEEPP Committee, 
you have contacted us and we have "volunteered" to work on this committee because of 
our strong belief in the cause. 

Since the time this activity started, everything has been so slow?! We don't even have a 
mailing list that works? 

Is there such a committee (SEEPP) or has it been terminated? If it still exists, what is 
going on? If it has terminated, then who did take that decision, why, and how come 
he/she never notified the volunteers as any professional would do????? 

Don, we are all waiting for your response. 

Gotterbam apparently appreciated El-Kadi's complaint, but took two weeks to respond. The two 
week delay seems to be explained at least in part by a December 11 email to Melford, SEEPP' s 
co-chair, that begins much as the El-Kadi's had: 

I have had trouble contacting you. I hope this email gets through. I am sending it to your 
computer.org address and home address. Below are two messages I will send out by the 
end of this week so people can start to get some work done. And make plans for attending 
a meeting of the task force. Let me know what you think.^^ 

Apparently, communicatrons between SEEPFs co-chairs had also become a problem (quite 
irriependent of ariy list). Gotterbam was now ready to solve the problem of Mdford's veto by 
treating silence as consent ("will send out") rather than as "I forbad". 

The first of the documents Gotiedem put "below", a letter beginning "Dear SEEPPers", 
seems never to have been sert. It consists of six numbered paragr^±is descrihang the steps by 
v\Mch the working groups should "get started" (a more detailed version of instmctions sent out 
February 22).^ ° The six are preceded by two introductory paragr^±is worth quoting in full: 

I am concerned by our lack of progress. I am not aware of airy working groups starting 
work. I know you have all been quite busy but we need to get started 

In March several of us m^ in Washington and wrote a statement defining the scope of the 
task force and reworted the formal procedures of deliverables from the task force. Bob 
has these documents and will forward them to the group. 

The message inplicit in these two paragr^±is is bleak indeed None of the working groups is 
working— or ever had (For some reason, Gotterbam chose not to mention El-Kadi's August 
email or other work that his own working group had performed since July.) The deadline is 
passed for delivery and all that Gottedem can think to do is to plead that "we need to get 
started". How do "we" get started? Gottedem's only answer, the second paragr^ii (and the six 
steps to follow), is to continue to go by the (IEEE's) book. He will distribute the documents 
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drafted on March 25, 1995, and (apparently) finished a few months later. How important are 
these documents? Not important enough for Gotterbam to have a copy of his own to work from. 
Melford will have to provide them. 

Gotterbam did not send this email to the list because Melford never responded to the 
request for approval. Gotterbam still held back from actually treating Melford's silence as 
consent. 

The other document "below" is a draft letter to the Professional Competence working 
group. Gotterbam begins that one by acknowledging El-Kadi's letter "expressing concem about 
the lack of progress... of our group". Gotterbam then apologizes for the lack of progress 
"especially to those who have already done work for the group". These preliminaries take two 
short paragraphs. The much- longer third paragraph tries to explain what went wrong: 

I have been concemed about the activity of the SEEPP task force. The last task force 
activity took place in March, when several of us met to finalize the task force guidelines 
and set the direction and scope of the task force. This material has not yet been 
distributed to the SEEPP working group leaders. As one of the co-chairs of the SEEPP 
task force, I have tried to motivate it from the bottom up by developing a plan of action 
for our working group and sharing that plan with other members of the SEEPP task force. 
Although you all started the work of our working group, there is very little happening 
from the task force and I did not feel right asking any more from you until I see some 
positive indications that your work will ultimately bear fruit. 

At the time, this explanation seemed unhelpful for at least two reasons. The first 
concemed the factual premise. Gotterbam said that the task force last met in March, completed 
the guidelines, directions, and task force scope, but "this material has not yet been distributed to 
working group leaders." Why, I wondered, weren't they distributed? Gotterbam does not say. 
More important— at least for those of us with a good memory or an email file (whether paper or 
electronic)— was that what Gotterbam said raised questions about the status of what all SEEPP 
volunteers had received by the email dated Febmary 22, 1995 (and presumably had been trying 
to follow ever since). That email contained— beside yet another copy of the Call— what looked 
like "directions" (the second part) and "guidelines" (the third part). Was Gotterbam referring to 
these documents or something else? What were these documents? What was their relationship to 
those completed at the March meeting? 

Gotterbam' s explanation was also unhelpful because what happened to the guidelines, 
directions or scope in March, however confusing, could tell the working group nothing about 
why so little happened after March. "Some" members of the working group had (according to 
Gotterbam himself) been able to do something. Why not others? Indeed, Gotterbam' s own June 
10 email showed that, even after March, he could set "direction", specifying particular jobs to be 
done. The cause of the working group's current sad state certainly did not seem to be his method, 
"motivating from the bottom". The one fact he cited that did seem relevant, that there was so 
little going on in the other working groups after March (or, perhaps, after June) that he did not 
"feel right asking any more of you", would be relevant only once he explained why so little was 
going on in the other groups . He offered no explanation of that. I think ordinary decision theory 
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does offer an explanation (or, at least a hypothesis worth investigating, especially for those 
thinking of learning from the mistakes of other code writers). 

SEEPP's general strategy had been "divide and conquer". The strategy works well when 
one can "conquer" a domain piecemeal— when, that is, the whole consists of (more or less) 
independent tasks, each a worthwhile objective in itself. When, however, the tasks are mutually 
dependent, so that none is worth doing unless all are completed successfully, and the work is 
divided among several different people or groups, then "divided and conquer" creates (what 
decision theorists call) an "assurance problem" (a certain kind of coordination problem of which 
the "prisoners dilemma" is a close relative). The parts gain their value (in large part at least) from 
their being included in an organic whole. Half a code is not (much) better than none. If nothing 
anyone does will be worth much unless all succeed at their individual tasks, doing anything until 
all can (as Gotterbam put it) "see some positive indications that [their] work will ultimately bear 
fruit" becomes irrational. Each must have assurance that others are doing their share before it is 
rational for him to do his. 

There are at least three ways to provide that assurance. One is to make it rational for each 
person to do her part even if others do not do theirs. The easiest way to do that is to pay for the 
work piecemeal, an option not open to a task force of the lEEE-CS/ACM Joint Committee 
without external funding. So far, all SEEPP's attempts to get a grant from the National Science 
Foundation or some private philanthropy had failed. The second way to provide assurance is to 
take a chance, that is, to do a little work oneself, see if others reciprocate, and then act 
accordingly, quitting if others do not but taking another chance if they do reciprocate. 
Gotterbam' s working group had, in effect, been trying to solve the assurance problem this way 
since June ("motivating from below"). The other working groups had not reciprocated— perhaps 
because they did not know that anyone in Professional Competence had done anything. (In this 
respect, Gotterbam' s failure to boast to the other SEEPPers about what his working group had 
done was a tactical error.) This second way of solving the assurance problem requires good 
communication between groups— or the ability of each group to observe the progress of the 
others. Individual members of SEEPP had a very poor idea what other members of SEEPP were 
doing. The listserv was not designed to track work— and, even today, it is hard to imagine how it 
could be. The third way to solve the assurance problem is to reformulate the task so that 
coordination across groups is no longer necessary. 

Gotterbam soon showed that he had chosen a fourth option (a "technological fix"): 
"Please have patience, I am taking a more direct approach to the problem." He had set up a new 
mail list "for our group" (PRFCMP-L(a)UTKCMl.BITNET). He would now be sending emails 
through a server at the University of Tennessee, Knoxville, rather than through a server at ETSU. 
The server seemed to be working: "This is the way this message was circulated." The list would 
transmit messages automatically: "Messages sent to the list will be forwarded immediately to all 
members of the group... .A reply sent to this message will be sent to everyone in the group." The 
working group would have a listserv rather than a mere list. (Apparently, Gotterbam was no 
longer worried about spamming or other abuse of the list.) 

With only the evidence Gotterbam had before him on December 15, we cannot be sure 
what caused SEEPP's work to come to a near halt after March. What we can be sure of is that, 
given the cause Gotterbam himself offered (the need for "positive signs that [their] work will 
bear fmit"), his "direct approach" had no more chance of success than his old approach— for a 
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least two reasons. The first is that in fact it was his old approach (except that the list was now 
automated). The problem existed even when the old list worked. The second reason his "direct 
approach" had little chance of success was that even if it were new, it would not have solved the 
assurance problem. That problem could not be solved without visible progress in the other 
working groups— or their dissolution (or some conviction that completing a part of the work was 
worthwhile even if the whole work was not completed). Gotterbam had no plan to improve the 
visibility of progress in other working groups, not even a common list for all of SEEPP, no plan 
to get the other working groups started except to try again to get his own group working, and no 
thought at all of dissolving the other working groups. Gotterbam had, it seems, run out of ideas. 

The paragraph announcing the automated list, when combined with his other emails for 
the year, suggests that Gotterbam may have mn out of steam as well. The paragraph concludes: 
"Three members of the group have already done some work in response to my July message. I 
will forward the material to you shortly.' Wlio were the three v\to had done something— or, 
rather, v\to beside El-Kadi had done anything? The material GotberiDam promised to forward 
would have answered that question, but he seems to have sent no more emails to SEEPP or his 
working group in 1995. The next Gotterbam email to arrive at IIT would be dated March 3, 1996 
(and would not contain the promised material). The first SEEPP-rdated email to arrive at IIT 
after Gotterbam issued his promise is dated December 28, 1995. While it was the sort of thing 
GotieriDam had promised (extracts of the "AICPA Standards Manual"), it was not forwarded but 
seems to have come directly from its author, Manriy Normaa passing through the new listserv— 
two weeks after Gotterbam had counted to three.^^ Gotterbam' s never-sent 'Dear SEEPPens" 
letter of December 11 contained a diagnosis of his own failings: "You have got to be ready to 
follow through. I have started n^^ group TWICE but each time I did not follow through." Here, it 
seems, was a third failure to follow through. 

Criticizing Gottertem' s performance is not hard: He had a problem he did not know how 
to solve. He tried his best but his best cleariy was not good enough. It is therefore worth pointing 
out that none of the other SEEPPers (that is, the chains of the various worldng groups) had 
offered any alternative to Gotteatem' s plan though he invited alternatives ty initially descrihang 
it as "written in Jdlo". Gottertem seems anything but a dictator. In addition, he had his own 
coordination problem As one of SEEPFs two co- chairs, he had (he supposed) to work with the 
other co-chair. In the first year and a half of SEEPP, the two had worked together pretty well. 
Melford had done much. He had recmited about half the chairs of SEEPP' s working groups, led 
SEEPP through the IEEE's serpentine procedures (preparing first drafts of the Call, Operations 
Guide, and Scope), and attended all but one of SEEPP's meetings (and shared with Gotterbam in 
planning all of them). But, as 1995 wore on, Melford had become increasingly hard to reach. 
Perhaps Gotterbam should not have been so quick to give up on the face-to-face meetings even 
though they seemed to accomplish little. One thing they had assured was that every month or 
two, Gotterbam would get to consult with Melford face to face, disposing of whatever business 
had not been completed by email. Melford' s own explanation of why he had become so hard to 
reach is that his consulting practice had becoming increasingly "crazy" (as the high tech boom of 
the mid- 90s developed) .^^ Whatever the reason, Gotterbam was finding it increasingly hard to do 
anything as SEEPP's co-chair. He never sent his "Dear SEEPPers" letter to SEEPP because he 
believed that, according to IEEE procedures, he could not properly do so without the consent of 
his co-chair. On his own, he could only communicate with his own working group. 
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4.7 Nadir 

December 21 is the darkest day of the year. We can easily imagine Gotterbam looking 
out on the gray round- tops of east Tennessee on that day's late afternoon wondering whether he 
was presiding over a disaster. He was, after all, no closer to having a first draft of a code of 
ethics than he had been a year before. Indeed, given the dwindling of enthusiasm among the 
volunteers, he was, it seemed, further from a first draft. And there was nothing more he could do 
about it. He had tried everything he could think to do. Nothing worked. He was now repeating 
himself, unlikely to succeed this time with fewer resources when he had failed earlier with more. 

December 21 is not only the darkest day of the year but the day on which the darkening 
ends. For the next six months, the days get longer, not shorter. December 21 is the ancient 
holiday of renewal. It would have been convenient for this history of the Software Engineering 
Code of Ethics if the crucial event in SEEPP's renewal had occurred on December 21, 1995. 
Instead, it occurred one week earlier. 



NOTES 



^ TTierevvere actually tliity-tMro responses by eariyjanuay^ 

because the respondents sinqiy asked to be tept informed and did not fill out the standard form 
(or otherwise provide the irrformation requested). Gotterbam' s first list of volunteers contains 
only twenty-four names (five less than the total number of respjndents even after these 
subtractions). Most of missing respondents ^Dplied before the November 5 deadline, but some 
did not It is unclear what the criteria of selection were. Gotterbam no longer recalls. 

^ One respondent sirr^y sent in an email answering most, but not all, the questions, 

informally. He is counted in tte 29. 

^ Though SEEPFs ratio of academics to practitioners is less lopsided than that of 

Anderson's committee, it still seemed lopsided to at least one observers "I was somev\tot 
concerned about the relative lack of practicing corrpjter scientists and software engineers on the 
task force- it seemed to me that vMle ethicists could perli^:s catalyze and facilitate discussions 
about software engineering ethics, there needed to be a stronger conpjnent coming from actual 
engineers v\to faced and ultimately had to deal with the ethical issues that arose in practice." 
Interview of Steven Barber, April 24, 2002. 

^ Gotterbam\SEEPP1994r95\Problems with SEEPP 6-8-95. 

^ Gotterbam\Steering Committee\eariy essay^Worlsgrp (2\13\1995). Typcal of the ten 

suggestions is the first: 
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Our— the seep— schedule has to be revised and made known to the working groups so 
that they have some type of target. The balloting process will consume a significant 
amount of time which I don't think we planned for. 4.3.2 has the task force conduct[ing] 
a ballot— we don't seem to have any provisions for consensus other than the ballot. 
Shouldn't consensus be achieved in the wg before something gets sent to ballot? 
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Gotbedam did not exclude other ways of canying on the work After descrihnng the 
second part of his plan, he returned to the sutgect of logistics. Though "for the present" meetings 
will be "electronic", there are "some national meetings that several of us will be at and we can 
gather in subgroups [there]". Further, if there is a "consensus" of the working group that "we 
need to discuss somdhing together", he can anange a conference call (though these are hard to 
organize, expensive, and therefore to be tept to a minimum). Gotberbam\SEEPP1994r 
95VProblems with SEEPP 6-8-95. 

' Gotierbam (comments on Ch^Dber 3, June 5, 2003) believes that "the operations guide 

was of absolutely no help— v\Mch part of it did we have to pay attention to ???— Look at the 
letter again It says here is v\tot we are doing— my plan arid then attaches the 'Guide to 
operations' ." Whether or not SEEPP had to pay ariy attention to the Guide, there are certainly 
obvious ways in v\Mch it did (or, at least, seems to have). For exarrqie, the Guide calls for 
division of the task force' s large project into smaller assignments for working groups. Gotierbam 
would later ask his working group to develop a Scope, just as the Guide required In February 
1996 (as we shall see in Ch^Dter 6), he recommended that Keith Miller be "the scribe" to 
comtane the documents expected from the worldng groups. And so on Gotierbam may not have 
taten the Guide seriously, but he said nothing then or later to indicate that; nor do his later 
actions so indicate. Gotierbam is, I think, reading into the past a hard lesson learned only later, 
that is, that the IEEE Standards procedures, even in Mdford's sinqiified form, could be of no 
help until someone had prepared a first draft of the code. 

^ Archive, February 22, 1995. The use of "fuses" as an exanqie suggests how much of the 

document may be IEEE boilerplate. 

^ Phone interview of Patricia Douglas, March 4, 2003. 

' ° Gotierbam\SEEPP 1994r95\Problems with SEEPP (6-8-95). 

" Gotierbam archive\SEEPP 1994-95\Problems with SEEPP (6-8-95). Gotierbam does not 
recall whether he sent this letter. 

'^ My most inportant publications on codes were then Michael Davis, "The Moral 
Authority of a Professional Code", Authority Revisited: NOMOS XXIX (New York University 
Press: New York, 1987), pp. 302-337; and Michael Davis, "Thinking like an Engineer: The Place 
of a Code of Ethics in the Practice of a Profession", Philosophy and Public Affairs 20 (Spring 
1991): 150-167. 1 have published a good deal more on codes since 1993. 
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Archive, December 12, 1994. 



'* Bumsbein received a PhD. in chemisliy in 1969 from IIT. She also has a masters in 
conpjter science from IIT ( 1984) and a masters in chemistry from the University of 
Maryland (1965). She was encouraged to enter the field of software engineering by a colleague 
in chemistry (^Dparently inp^ssed by her facility in programming). However, her first formal 
involvement in conpiter science teaching had another origin She was volunteering as a 
"conpjter mother" in her children's elementary school. She ergoyed working with children and 
thought teaching them a great opportunity to use the programming she had learned as part of 
training in chemistry. That experience was one of the factors that got her interested in going back 
to graduate school in conpiter science and in teaching in that field Bumstein had been 
programming (software) since the 60s. Interview of Ilene Bumstein (May 14, 2002). 

^^ The confusion may run deeper. Gotterbam's archives include a list of 23 under the 
heading "MEMBERS OF THE INFORMED CONSENT MAILING LIST". Infom^ Consent is 
not one of the original eight working group. But among its members are IIT' s three (Bumstein, 
Weil, and me) as well as Gotterbam, Mdford, and Miller— and mari^ others familiar from the 
lists Gotterbam drew up of the members of other working groups. 

'^ Though the list itself had a title cleariy identifying it as the list of the working group, 
there are two reasons v\^ that clarity may have been lost One is sinqiy that the format in v\Mch 
the email was printed (all the routing codes) made ovedooking the title easy. The other reason 
the clarity may have been lost is that the email's Sutgect is "current list of volunteers", not 
"current list of Professional Conpetence volunteers". 
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Archive, June 10, 1995. 



'^ A review of the addresses on Gotterbam's June 6 rnemos seems to explain why we did 
not receive those. Only n^^ name is on the list and n^^ address had become cormpted, that is, 
been mixed up with an ETSU address (CSEP(a)IlTVAX .EAST_TENN_ST.EDU). Explaining 
why we did not receive the July 1 memo is more difficult WeQ is back on the list (though 
Bumstein is not) and both her address and mine now seem correct ((©CHARLIE ACC.IIT.EDU). 
Mechler Archive, E950610, E950610A, and E950701. Mechler had sent his own summary 
directiy to GotteriDam, not to the list allowing Gotteatam to distribute it 

^^ Mechler archive, E951103B. 

^ ° Mechler archive, E951 104. 

^' Mechler archive, E951106A. 

^^ Mechler archive, E951108. 
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^^ Mechler archive, E951 1 14A 
^ * Mechler archive, E951 1 14B. 
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The Englishman v\to "hailed from India" would respond on November 22, bringing the 
total of 'live" volunteers (including Mechler himself) to eight: "I also sent a message to chair 
without smy respjnse. When Mario Barbacd was here in September he was hopeful that this 
exercise would be conqieted and that volunteers are working on it I am not sure that we are 
progressing." Mechler archive, E951122. 
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Mechler archive, E951109A. 
Mechler archive, E951116. 
Mechler archive, E951116. 
Gotterbam\Prfcn5>l archive\BOBOUTASC 



Gotterbam\Prfcnp-l archive\BOBOUr.ASC. The title of this part of the document is 
"MESSAGE TO BE SENT TO MY TASK FORCE ON PROFESSIONAL COMPETENCE". 
Apparently, even Gottertem had trouble teeping terms straight: he should have said 
"WORKING GROUP". But, of course, this is a draft; not a final docunoiL 

^ ' Gotterbam must mean 'June", not 'July". While there is a July 1 email (that IFF did not 
receive), it does not fit the description (an email calling for work). Apparently, Gotterbam is 
working from memory (miscued, perh^:s, by Mechler' s reference to 'Jul/')- 

^^ Who then were Gotterbam' s "three"? Even if we count Manny Norman as the second, we 
have a third to account for. One possibility is Mechler. By then, he had done "some work" (as we 
shall see in Chapter 5). Another possibility is Nayarana Jayaram (the Englishman who hailed 
from India). As he recalled (interview, February 25, 2003): "I collected British codes and did a 
comparison... .1 sent the results to Ed Mechler in Pittsburgh, Amr El-Kadi in Egypt, and some 
others who were doing something similar. We wanted to see what the state of the art was." While 
Jayaram' s memory places these events two years too early ("at the end of 1993 or the beginning 
of 1994"), I think it reasonable to add two years to his memory. (After all, he did not volunteer 
for SEEPP until the end of 1994.) Even so, for Jayaram to be the third, we must suppose that one 
of the "others" to whom he sent his work was Gotterbam (or that someone else relayed the work 
to Gotterbam). Gotterbam's archives provide no evidence that he received Jayaram's work (or 
Norman's or anyone else's but El-Kadi's). So, we have a mystery. Indeed, the mystery runs 
further. Jayaram's work does not seem to have survived at all. It may be another victim of the 
ETSU list. Gotterbam has no explanation. Those of us who have lost files as we moved records 
from one computer to another can sympathize. 
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^^ Interview of Robert Mdfoid, October 31, 2002. Apparently, it took Mdfoid almost a 
year to realize the craziness would not soon go away: "I had to discontinue n^^ irwolvement in 
late 96, early 97, because n^^ own work had gotten too crazy." 
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Chapter 5: Version 1.0, the Miracle of '96 

"No system is so perfect that it cannot be made to work." 
— Anonymous Engineer 

5.1 MechlerWho? 

Edmund Mechler had worked for several years in the engineering department of a 
Pittsburgh natural gas utility before he became a SEEPP volunteer. He managed projects 
concerned with developing special computer systems, geographical information systems, and 
special document handling systems. He saw SEEPP' s work as an extension of what he was 
trying to do in his department: 

I basically thought... the software industry [keeps] going around in circles. And at that 
time they were really going around in circles. The material that they handled is really not 
that complex. In fact the computer is really a simple-minded thing. But there's so many 
pieces of the simple mind. And we kept going around in circles, almost like reinventing 
the wheel. And I figured, well,... if they put an engineer behind it and they get the people 
to start doing that and take it out of the realm [of do it your own way], maybe we can 
really concentrate on making it an engineering thing that really builds on itself and starts 
moving ahead instead of just keep going around in circles. I mean, even now [2002] you 
can pick up a book and it's a matter of terms. And soon as you figure out what the terms 
are, you're right back 10 to 20 years ago. It really doesn't change. 

Mechler seems to have been an ordinary software engineer. While working as an 
electrical technician at MET' s Instmmentatron Lab (hdpng to develop hardware and software for 
research applications), he decided to become an electrical engineer and started taking classes at 
Northeastern University in 1970. After four years at the Instmmentation Lab, he returned to 
Rttsburgh, planning to pursue his engineering degree full-time at to the University of Pittsburgh. 
But, faced with "a lab four hours a night [once a week] for one credit", he switched from 
engineering to mathematics (which, in those days, did not require labs even though it housed 
computer science). Mechler graduated cum laude with a BS in Mathematics in 1976 and, having 
avoided that four- hour lab, returned to engineering, receiving a master's degree in industrial 
engineering from Pittsburgh in 1979. He then worked for industry, primarily in engineering 
(electrical, computer, or industrial)— at first in hardware and then software. Eventually, Mechler 
moved into project management, "the communications part of" software engineering and was 
certified as both a CCP (Certified Computer Professional) and a PMP (Project Management 
Professional). Though he lived and worked in Pittsburgh during the early years of the Software 
Engineering Institute, Mechler had had no contact with it when, early in 1995, he first learned of 
the joint lEEE-CS/ACM project from a trade publication, IEEE Institute.^ He immediately 
contacted Mdford Mdford had lEEE-CS fax him a conqiete Call (February 6). The final two 
pages of the Call contained a blank ^plication form. Mechler filled it in and faxed it to Mdford. 
Mdford emailed Mechler on March 2, acknov\dedging recdpt of the ^plication and assuring 

90 



him that "of course you are a member of the working Group(s) you checked off." He also warned 
Mechler, "As this is a volunteer effort, our turn-around times tend to lag. You should receive 
some confirming e-mail in a week or so. If you don't please let us know!' 

Mechler chose SEEPP over the other two task forces because it was, as far he knew, the 
only one at that time asking for volunteens.* A middle-level technical manager in a utility, he was 
concerned with getting those he woited with to follow standard procedures.^ "Professional 
Conpetence" (Gotterbam's working group) seemed the category closest to that concern But, 
lite Gotterbam, Mechler saw participation in that working group as a step toward certification 
As he wrote a friend (March 13, 1995): 

Did you know that the IEEE Conpjter Sodely and the Association for Conpjting 
Machinery have formed a Joint Steering Committee for the establishment of Software 
Engineering as a Profession[?] Pait of v\Mch is certification I have joined a worldng 
group on professional con^Detence and hope to join one on certification But.. the 
education issues must be solved before certification[,] according to Dr Mario Barbachi 
[sic] of the Software Engineering Institute, the head of the Joint Steering Committee 
[v\tom Mechler had tailed to by phone eariier that day] .^ 

Mechler had called Barbacd because he had heard nothing from Gotterbam' s worldng group and 
was anxious to do something. He told Barbacd he was willing to "assist in any edacity you may 
need". He specifically expressed an interest in the following sutgects within the Body of 
Knov\dedge: Communication Real Time Systems: Client/Server) Project Management and 
Parallel Conpjters.' 

On April 21, Mechler wrote Mdford again "I haven' t heard from you for a vMle. When 
will the committee be in action?"^ Mdford responded four days laten "Apologies for the dday, 
Ed You should recdve e-mail this week or next"^ While we do not know v\tether Mechler got 
the email (presumably from Gotterbam) within the next two weeks (as promised), we do know 
that Mdford had informed Gotterbam of the new volunteer by June— because Mechler recdved 
two emails from Gotterbam on June 10.' ° Gotterbam had not yd added Mechler to the basic 
profconp list so, v\tot Mdford recdved was v\tot looks lite a forward of the profconp 
message. The first email laid out a general plan the second listed some codes of dhics to "look 
at' and asted volunteers both to choose some to report on and to Id Gotterbam know v\Mch they 
chose." This was just what Mechler had been waiting for. "We started out very easy... lets look 
at some other codes and see what we can get out of [them]. That s not a bad idea."'^ On June 29, 
he sent in two summaries: one of the IEEE code; the other for the National Soddy of 
Professional Engineers.'^ On July 1, Gotterbam sent these to profconp list with encouraging 
news about what other volunteers were doing: 

We have some volunteers for the second item in the task list [of June 10]. Ed 
Mechler has junped in with some engineering codes. I have ^Dpended his contribution 
Since we are interested primarily in conpetence, it might be useful to write a litfle hat 
about v\tot each code says or fails to say about con^Detence. This will hdp us get a 
discussion started Ed . .would you be willing to cany your work this one fuither step.' * 
Jod Fineman is looking at BAR assodation codes, aril Amr El-Kadi has offered to work 
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on some of the other codes I listed, e.g., the business communications and the 
conservation codes. He will also look at the Microsoft Certification Success Guide by 
John Mueller... I will look at the ACM and British Computer Society Codes. Thanks for 
being willing to help. 

We still need volunteers for the first and third tasks on my initial memo. I am 
working on setting up a listserv for us. I will let you know. If any of you can do this 
easily (I have to convince another university [University of Tennessee] to loan us their 
facilities) it would be great if you could set this up. Let me know.^^ 

Some of the other volunteens also did summaries, though the only one to go out through 
Gottedam' s list came from El-Kadi (August 31). 

Sometime late in the fall (as he recalls), Mechler began to wony— and to act 

In the beginning, v\ten we were asted to review the models [other codes of ethics] in 
SEEPP, we were given a deadline for the first copy [of the code]. To a project manager 
this is very inportant When I couldn't get ariy answer from the emails [to Gotberbam] I 
just took over to meet the deadline.' ^ 

Mechler was not in a good position to "tate over^'. "I knew there was a joint task force [steering 
commitbee]. I knew there were three commitbees [task forces]. How SEEPP was structured, I had 
no idea"'' He had no idea how large Gotbertem's working group was— or, at least, was 
supposed to be (even though he had the email addresses on Gotbeibam's header). He thought of 
the working group as consisting of a "half a dozen" people.' ^ 

5.2 Starting from Zero 

On December 4, 1995, Mechler emailed that "half a dozen" (with a "cc" to "Barbachi, 
PhD."— because Jayaram had suggested teepang him informed)." The half dozen (beside 
Jayaram) were: (Marmy) Norman, El-Kadi, SuUivan, Bumstein, and Weil. (For some reason, n^^ 
name was not among the half dozen.) That email began much lite one of Gotteibam' s. Mechler 
was writing only to those v\to had responded to his November email; he had communicated with 
Gottertem separately ("l finally got in touch with Don G. and he reported there were problems 
with the group no reply to v\tot yet"); he (Mechler) had a plan for haw to proceed But having 
started as Gotteibam might have, Mechler did something that Gotterbam had not done. He 
"note[d] some of the work I have been doing, some additional resources, and a preliminary 
outline." The "preliminary outline", a page and a half long single-spaced, was something new— 
in effect a rough draft of a code of dhics (though also very lite the code summaries Mechler 
had done). It began: 

INTRODUCTION 

SY STEM DEVELOPMENT 

Evaluate business affects [sic] and culture changes 

Inqiement Ethical evaluation. 

Assure proper Goals and Otgectives 
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Assure proper Development Methodology 

Assure proper Project Management 

Assure proper testing, debugging, Case Tools, GUI, etc 

Only approve safe and accurate documents 

Assure proper privacy, accuracy, property, access and people 

There followed similar lists of rules for "PROFESSIONAL PRACTICES (Himself/Herself)" 
AND "PROFESSIONAL OBLIGATIONS (Othere)". Mechler offered this list as a "starting 
point": 

I agree with Manny [Norman] that we should have reviewed more examples but I did not 
see any from the membership; if you have an outline please pass it on. I did two and have 
asked for ACM version plus reviewed some articles so I have developed this prototype. I 
have tried to organize the subcategories but not all that good, feel free to change. Also, 
[feel] free to change anything else. Please return comments by the end of the year... . I 
plan to mix in all your comments and get your approval of the outline by Feb, 1996. Then 
we can decide what the final version for submission should be like. 

Mechler had, in other words, bypassed the various IEEE stages Gotterbam had regularly set out 
(before Mechler began receiving SEEPP mailings). Mechler had also ignored the role of the 
other working groups (from which he had heard nothing). He even ignored the distinction 
between "code of ethics" and "professional practices" (something else lost in documents "before 
his time"). He had simply jumped into drafting a document that was to look something like the 
documents he had been examining. This may seem like the wrong way to write a code of ethics, 
to work on the upper stories before a proper foundation has been laid, definitely not the way to 
write a complex software program. But this "starting point" grew into "Version 0" of the 
Software Engineering Code of Ethics (see 5. Appendix). It was in fact the beginning of what 
Gotterbam had called a "straw man". 

The effect was immediate. Though I had intended to remain a quiet observer, I responded 
on December 5 with an email entitled "Additions to your e-mail list of December 4, 1995": ^° 

"Accept responsihality...." Hovv atout sonietiing atout environrnent? Software, in many 
uses, may have substentral inpact on the environment not clearly covered under "public 
health, safety, and welfare." I believe dvil engineering now has such a provisron 

"Assure enployees know..." Good Now, v\tot about enployers and supervisors? If a 
software professional doesn't pro-activdy assure that they know the constraints he 
operates under, they may react with anger rather than understanding to a mid-crisis 
announcement that "I can't do that because it is against my profession's ethics." For 
exanple, certified financial analysts are supposed to give their enployers a copy of the 
CFA code of ethics each year (and must certify to their association that they have done 
so). 

Otherwise, a thorough list Very good job. 
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When I wrote these comments, I imagined they would be one set among half a dozen. In fact 
they seem to have been the only comments. So, on December 14, Mechler wrote his handful of 
volunteers again (now seven with my name added)— with the uninformative subject heading 
"Copy of: Continuation- More": 

Volunteers 

Here is some additional info from 

The Unwritten Laws of Engineering -W.J. King 
Pa State Registration Board of Professional Engineers, 

Land Surveyors, and Geologists Newsletter 

concerning registration law. 
Michael Davis-Works at the IIT Center for the Study of 

Ethics-Response to Continuationsl2/4/95 

INTRODUCTION 
SYSTEM DEVELOPMENT 

Assure proper estimates 

Assure specifications are fully understood 
PROFESSIONAL PRACTICES (Himself/Herself) 

Add environment issues to "Accept Responsibility .." 

Faithful Agent 

Put forth best effort 

Show initiative on projects 

See through to successful finish 

Don't try to do it all yourself 

Don't ignore signs of trouble 

Don't dodge the issues 

View matters from others points of view 

Accept full responsibility 
PROFESSIONAL OBLIGATIONS (Others) 

Assure employers and supervisors know of code of ethics 

Voice concerns 

Don't supplant another engr after steps have been taken 
for employment 

Fair and just compensation 

Never invade another division's domain without knowledge 

Give fair hearings 

Don't prevent better opportunity elsewhere 

I hope to hear from all of you soon. 
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These new items would be added to the first "straw man". Norman responded the same day with 
an apology: "I hope to get my stuff about the accounting profession out over the Christmas 
break. Life is just so busy during work times!" He was as good as his word. On December 28, 
he sent out his extracts, using Gotterbam's "list" (rather than Mechler's visible list of addresses). 
On March 18 (almost three months later), Mechler emailed the "final outline" to his seven (with 
a cc to "M. Barbachi, Ph.D" even though Barbacci had become lEEE-CS President in January 
and Felipe Cabrera had replaced him as chair of the Joint Committee):^^ 

Volunteers, 

I have not heard from Don Gotberbam since his e-mail dated 12/15/95; if ariy of you have 
heard please let me know. I do not know the conditions of Task Force or Steering 
Committee; this is v\^ Mario is cc. Well, on with our task. 

Bdow is the final outline; exanples are getting too repetitive. It has been updated from 
Manriy's e-mail dated 12/28/95 (please Manriy change anything you want) and Project 
ManagenierTtlnstitutesCtodeofElMcs. I vvodd suggest the next step be: eachof uspcka 
section and add words to mate it more readable i.e. Article I: Software Engineering 
Professionals in System Development 

must assure the following factors: (did mine! ! ! ) 
Please pck a section or propose another ^Dproach and let me know ty 3/25/96. 
We will try to conplete the task ty 4/15/96. 

Mechler sounds optimistic in this memo. But a conparison of what he said with v\tot he did not 
say suggests that he had not yet solved Gotterbam's problem (getting the working group to 
work). First he explicitly mentions only Norman's ("Manny's") contribution. We have no 
evidence of any other (except mine). So, even among Mechler's small group, only three had 
contributed anything to the code— and, of these, Mechler alone had contributed almost 
everything.^ ^ 

Second, two days later, Mechler e-mailed "the remainder of our new sub-task force" to 
announce that he was "assuming a facilitator position, if there are no olgections, to bring this task 
to some degree of conqietiorL" He was in effect taking over Gotterbam' s position as head of the 
Professional Con^Detence worldng group— except, ^Dparently, he had not yet realized that there 
was such a worldng group and thought his sub-group the remnant ("remainder^') of the task force 
(rather than of the worldng group) . Hence, from thai on, he would occasionally use the acrorym 
"SEEPP/E" for his "sub-group".^^ 

Having in effect replaced Gotterbam, Mechler seems to have begun to think in the same 
ordedy way Gotterbam had Mechler did not stick to the plan he had announced two days before 
but returned to (something closer to) Gotterbam's: 

Frrst we should agree on [what] the final product should look lite. I lite an intra 
sentence with bullets. Most of the ones [codes] I review[ed] were lite this. Please agree 
or suggest options ty 4/8/96. Then we will divide the sections between the members. 
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Third, Mechler does not seem to have expected much to come of his suggestion that the 
format be chosen first— or that "each of us pick a section and add words to make it more 
readable" (Gotterbam's "divide and conquer" again). On the same day that he sent off this 
general email, he emailed me: 

I will be in CHI from 4/1 to 4/3 at the AIIM Conference at McCormick Place. Is 
it near you? How about lunch? 

I accepted the offer two days later, curious to know how much Mechler in person would 
resemble the Mechler of so many emails. We met on April 2 at my CSEP office and walked the 
mile to Chinatown for lunch. (Mechler looked like a college professor or senior engineer, 
average height and build, silvery hair, only a warm smile to distinguish him from a great many 
other people.) After much sociable back and forth over dim sum, Mechler announced that no one 
had come forward to "provide the words" for his outline and that he now worried that no one 
would. The work would come to nothing unless a "Thomas Jefferson" appeared to do for the 
code what Jefferson had done for the Declaration of Independence. No such person had yet 
appeared. Mechler was not himself the person; his skills lay elsewhere. The tone of Mechler' s 
voice, the pleading look in his eye, the unfolding of his hands, convinced me that he was asking 
me to be the code's Jefferson. 

I had only one good reason to refuse. I thought of myself as a mere observer {participant- 
observer only in the sense that I was not to stand out as an observer but blend into the crowd of 
participants). My two small suggestions of December 5 had made me a marginal participant. To 
do more, to do for the software engineers' code of ethics what Jefferson had done for the 
Declaration of Independence, was to move from the margins of the process to the center, 
potentially changing the dynamics in ways hard to predict but certain to invite questions about 
whether the process was typical. The process (and the code) might have too much of me in it, too 
little software engineer. Volunteering to draft the code might hopelessly contaminate the process 
CSEP was supposed to study. 

On the other hand, the process seemed about to come to a halt— again. And, given the 
few volunteers who still were active, this halt might not be so much another halt as the last, final, 
and disastrous end of the project. To fail to help draft the code might well mean there would be 
no drafting to study. An unusual opportunity would be lost. In this moment of crisis, the risk of 
contamination seemed worth taking. 

I did not know why Mechler had picked me (except that I had showed interest and 
apparently could write), but I did think I could do a good job.^'^ Though a philosopher (PhD., 
University of Michigan, 1972), I had had a year of law school (1976-77, also at the UM, v\ten I 
could not find a job in philosophy). Among the usual (lequiied) first-year courses, there had been 
one elective. I had chosen conpaiative law and learned much about French and Gennan legal 
codes, including the experimentation and theorizing that preceded them I had been especially 
inp:essed ty the way tte m^or nineteenth certuiy legal codes con±aned "general clauses" (such 
as "An immoral transaction is void") with more specific lules ("Where the sutgect of a 
shareholders' resolution is the ^Dpointment of auditors for the examination of certain events 
connected with the organization or management of the corporation, those shareholders v\to are 
directors or officers of the corporation may not vote"). Tte summer after n^^ first year of law 
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school I clerked for the Secretary of the Michigan Law Revision Commission (a UM faculty 
member). The subject of the laws he helped to revise that summer was special assessments, a 
subject only a real estate lawyer could get passionate about. But the problem of putting more 
than a dozen independent statutes into a single, sensibly organized, easy to use, and politically 
acceptable form was not so different from the problem Mechler's list now posed. 

I also had an interest in professional codes going back to the 1974-75 academic year, 
when I had taught legal ethics at the law school of Case-Western Reserve University. Lawyers 
were just learning to use the new Code of Professional Responsibility (1970) after abandoning 
the old Canons of Ethics (originally adopted in 1908 but much amended since). The Canons were 
a simple list of do's and don't's, not so different from Mechler's Version 0. The new Code was 
divided into seven Canons (general provisions). Under each Canon were several specific 
Disciplinary Rules (enforceable) and Ethical Considerations (the exact force of which was a 
subject of controversy even though the Code's "Preamble and Preliminary Statement" described 
them as "aspirational"). Because this three-level structure did not correspond to any other 
document with which lawyers generally worked, there had been much discussion among them 
about what codes should do and how they should do it, a discussion that led to the abandonment 
of the 1970 Code in 1984. The code that replaced it {The Model Rules of Professional Conduct) 
had the standard format of a model statute, that is, mandatory rules with commentary to explain 
how to interpret the rules. Any "aspirations" went into the commentary as guides to 
interpretation. 

I had begun writing about professional codes in the mid-1980s.^^ I had begun studying 
engineering codes about the same time.^^ I had even written a theoretical pece with part of a 
modd code in it (though one concerned with governmental ethics)." I fdt that I had been 
preparing to be some professional code' s Jefferson for a long time. While I knew that I knew too 
little about software engineering to write its code alone, I thought I could count on Mechler, n^^ 
colleagues at IIT (especially Bumstein), and perhaps some other volunteers to conq^ensate for 
n^^ ignorance. 

I should, however, not then have made the decision to draft the code. Even though the 
NSF grant that had brought me to lunch that day had explicitly treated providing technical 
assistance as one of the purposes of the grant, the decision to provide that assistance belonged to 
the research group, not to me alone. I should have told Mechler that I was inclined to volunteer, 
if Mechler would have me, but that I could not volunteer unless the research group agreed 
Mechler would no doubt have understood— and waited Instead, I immediately said I would try 
to do adraft, perh^:s hinting thati would have to consult Weil to besurel could do it Mechler^s 
response was enthusiastic. He left no doubt that he had hoped I would volunteer.^ ^ 

We should not conclude from these events that Mechler scheduled the lunch in order to 
recruit me as "wordsmith" (or, at least, not with that purpose alone). Mechler had just had a 
lesson in the inp^rtance of visiting with members of the working group v\ten passing through 
town On March 18, he had received an email fromjayaram— v\Mch read in part 

Regarding the elusive Don Gottertem, you are singulariy lucky having got his 
email [of December 15, 1995]. He was in LONDON during Feb 2nd of this year 
presenting his p^:er— you guessed it— on ethical issues in SE! This Conf titled 
"Professional Issues in SE" was organized by niy colleague (who shares the office 
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space with me!). All that was required of Don— if he was remotely interested— 
was to give me a call spending as little as a quarter or ask my colleague who was 
a CO- chair or take a brisk walk worth 15 minutes from the venue or use his 
subway ticket purchased for the day for a 5 minute ride TO GET ME AT MY 
UNIVERSITY (I had to take my graduate- level classes that day)! 

While this e-mail also complains of Gotterbam's failure to respond to e-mail (a subject to which 
we will return in Chapter 6), its heat suggests that no amount of email could substitute for the 
courtesy of a personal visit. Gotterbam did not visit Jayaram because, though attending the 
"Westminster PASE'96 Conference London", he did not realize that the "(5) Westminster" in 
Jayaram' s email address meant that like the conference, Jayaram was located in that part of 
London (once an independent city) in which Westminster Abbey is located.^^ Gotbedam must by- 
then also have forgotten the list of working group members he had last updated nine months 
before; Jayaram' s address there is 'T/)ndon' . ° 

Jayaram knew that Gotterbam was at the conference because Gotbedem gave a p^:er 
(actually, two) and so had his name listed in the conference program But Mdford' s name dso 
^Dpeared in the program; he too gave a p^:er. Mdford also did not look Jayaram up.^ ' Why did 
Jayaram not also conqiain about Mdford' s failure to pay a courtesy call? There are two possible 
escplanations. One is that Jayaram was thinking of Gotterbam as leader of Jayaram' s working 
group— and was conqiaining about his conduct in that edacity (rather than in his cspddty as 
SEEPP co-chair). That Mdford was the other SEEPP co-chair would then be irrdevant The 
other possible explanation is that Mdford' s name no longer meant ariything to Jayaram Mdford 
was by then invisible to most members of SEEPF s working groups (or, at least, of Gotterbam' s 
working group). For a long time now, the only messages from SEEPP (or ariy of its working 
groups) had come from Gottedem Qf these two (conq^atible) explanations, the second seems 
the more liMy. Lite marry other members of Gotterbam's working group, Jayaram may have 
lost track of the distinction between SEEPP and the Professional Conpetence Working Group. 
For him, the working group was SEEPP and SEEPP was Gottedem 

Mechler naturally assumed that Gottedem meant no discourtesy and decided to prevent 
such an oversight from weaterdng his "sub-group". So, on March 19, he told Jayaram that he 
had taten "the liberty to send [your reply] to tte other team members working on the ethics 
outline". Then, on April 5 (after his meeting with me) he emailed the sub-group 'Just in case 
any of us travd I would lite to list v\tot dty each of you lives in If one of us travds to a 
member^ s dty we could meet" He then listed the dght members of the group (including himsdf 
and me), asking each to email his or her location Qn April 10, he emailed to all a list with 
location for each. (Plainly, the five v\to had had nothing to say about Mechler^ s "straw man" 
were still reading thdr email and anxious to stay involved: they had all sent in a home town)^ ^ 

5.3 "Mr. Jefferson" atWoric 

A few days after my meeting with Mechler, I informed Wdl that I had agreed to do a first 
draft of the code.^^ She approved. She had missed the meeting only because she was out of town. 
She had already tried to help Mechler get on with the writing— without herself consulting the 
research group. On March 25, she had written: "I am glad to see the work going forward. Your 
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list of March 18 is quite comprehensive. Do you plan to put the imperatives in categories with 
rationale or preamble to each category?"^^ Mechler lespjnded the next day that he was "open to 
discusaon Maybe give an exanqie of one of the categories. I wasn't niyself but each member 
can tate a part or suggest a form." Weil had concluded from this exchange (especially, from the 
request that she give exanples) that Mechler had done all he could and that the group as a v\tole 
would not do more. Shehalheiself begun to think of who might be brought in to do the writing. 
She had come to the same conclusion as Mechler. 

During our April meeting in Chinatown, Mechler and I had discussed schedule. I had 
pointed out that I was in the last weeks of the semester. I could not do much before May. On 
May 2, Mechler emailed a reminden "During our meet in Chi. you said that you would add the 
'good words' totheethicsoutline. Was the text copy I sent ccgocderDu^ for this task? L^rne 
know if you want a p^:eiywORD/WordPerfed/etc. copy." I responded (May 8): "WordPerfect 
copy would help. Probably cannot finish job before June 15. O.K."^^ On May 15, Mechler 
emailed "With regard to adding words to the outline, I am sending you a disc with three versions 
[of WordPerfect]. Let me know if one is ok. Also have dos and secondary file if you want June 
15 ok for finish date." The distette anived about the same time as tte email. I set to work 
immediately.^^ 

By May 24, I had a rough draft— and several problems on which I wanted Mechler' s 
advice before I went further. I wanted Mechler^ s advice for three reasons: 

First, it turns out that there are some clauses v\Mch, when I started trying to put into 
prose, I realized I didn't understand (See ?'s.) Second, there are some clauses I didn't 
know what to do with, either because they didn't seem to belong in an ethics code (too 
specific), because they seemed to repeat v\tot I already had, or because I couldn't figure 
out v\tere to put them. (Hence, the unnumbered clusters at the end of some sections.) 
Third, I have found myself rearranging your list. Have I missed something I should have 
seen; or have I really made an inprovement? 

Because I had also changed Mechler^ s (conpjter) formatting, I "didn't dare to send" the draft 
email. I therefore asted for Mechler' s fax nurnber. 

Mechler took four days to respond His four paragr^iis suggest that he had a lot to think 
through before responding. He declined to let me pass the buck "mainly you must decide how 
far you want to go adding words." He then acknov\dedged an issue that I had not raised in my 
May 24 email: 'From our conversation in Chi., I believe that you did not want to go too far due 
to your two roles. In fact, vMle reading your e-mail a question occurred; v\ten I pass this around 
to the other men±)ers of the group do you want credit or should I say an anorymous men±)er 
added words?" He then returned to my questions, offering a few options but, essentially, giving 
pemiission to do v\totever I thought best: 

In regard to your specific questions, they all seem reasonable but should I or the group 
answer? There is no doubt in n^^ mind that you had to rearrange clauses, found duplicate 
clauses and ones that are hard to place, if they can be placed Also, how far should you 
go? Maybe the effort you have already conqieted is enough and I [should] pass around 
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the results plus questions? Let the group finish the effort. I must leave these questions up 
to you because of our conversation in Chi. 

Recalling that what Mechler had said "in Chi" was that he had gone as far as he could, that there 
was no one else to do it and that unless I did it it would probably not be done, I replied on May 
30: "Y our email of May 28 gave me courage to do one more draft (if you find the document I 
sent you to be basically what you had in mind)." 

Most of my email is, however, about how to present the draft once finished, to SEEPP/E. 
I thought that Mechler, not I, should send it out in part "for practical reasons". In the past CSEP 
had had trouble emailing large documents. CSEP's librarian, "the email expert", had just 
resigned, moved to Denver, and not yet been replaced. But in part, I thought that Mechler should 
send out the draft because it was "important that at least one software engineer is happy enough 
with the document to put it out." That Mechler had to "put it out" did not mean the draft need be 
anonymous, only that Mechler "should make it clear that I am trying to work within the list of 
do's and don'ts the group developed, providing a framework rather than new substance." I 
concluded by promising one more draft if Mechler' s comments "are mostly favorable." 

Mechler took almost a week to respond (in part because my email arrived late on 
Thursday, after he had left work, and he did not return to his office until Monday). But his 
response, when it came (June 6), was certainly favorable: "I just read your draft and have only 
one word for it EXCELLENT EXCELLENT EXCELLENT EXCELLENT. It is a great step 
forward." He then suggested that "when you find a statement that is unclear or you do not know 
if it fits put 2 or ??? to highlight the condition." Just to be sure I would not take this minor 
criticism too hard, Mechler concluded the email as he had begun, with praise: "Really looking 
forward to the review draft Again an excellent job, just what I wanted." 

My next communication with Mechler is a "classic mail" letter with the same date as 
Mechler' s email Qune 6). The letter seems to begin with an (understated) acknowledgment of 
Mechler' s approval: "I took your comments to mean continue. So, I did." Enclosed with the 
letter was "your disk with the draft code of ethics". Mechler was to "note that this is (more or 
less) on time and (certainly) within budget" The letter concludes with me looking forward "to 
your response, but especially to the responses of all those connected to us only by email." 

A closer reading of my letter shows that it is in fact not a response to Mechler' s email of 
that day. Mechler's letter was received at "15:50:41", rather late in the afternoon on Thursday. 
How could I revise the code as instructed, put it on disk, and write my covering letter, in what 
little remained of the working day? Memory does not answer that question, but there are at least 
three reasons why it is improbable that I rushed out a response. First I had no reason to rush. I 
had originally given myself till June 15— and Mechler gave no indication of holding me even to 
that date. I had more than a week until that target date and, given SEEPP's history until then, a 
week or two beyond that date should have bothered no one. Second, I generally worked on the 
code at home because I considered such writing to require concentration. The office was for 
work that would not suffer from frequent interruption. Third, there is an email that seems more 
like a response to Mechler's. That email was sent on Monday, June 10. In it I inform Mechler 
that a diskette "(with a somewhat revised version of the code you saw) is in mail. Please put in 
'???' as you see fit (all unnumbered phrases)." Apparently, I did not receive Mechler's Thursday 
email until Monday. (I generally did not come to tiie office on Friday during the summer.) I had 
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worked on the code without Mechler's four EXCELLENT s; hence, I could not follow Mechler's 
suggestion about the use of "???" and had to have Mechler add them himself. ^^ That I sent 
Mechler the revised version on the same day that Mechler^ s email arrived with its praise, seems 
to be pure coincidence. 

So, v\tot were the comments Mechler had made that encouraged me to do one more 
draft? They should not, it seems, be those of May 28, since I said I would do one more draft if 
Mechler's comments on the draft on which Mechler had not yet commented were "mostly 
favorable". Mechler's June 6 comments were the comments I was supposedly waiting for before 
doing another draft. Did Mechler send any comments between May 28 and June 6? The archives 
contain none. No one recalls any. And the tone (and substance) of Mechler's June 6 email makes 
it doubtful that there was any communication in the intervening week. So, it seems, I had not 
waited for Mechler to comment. I had taken Mechler's May 28 email as permission to continue 
with detailed revisions even as Mechler assessed the overall document ("mainly you must 
decide"). I expected Mechler to approve and acted accordingly. What I did not expect was that 
Mechler's approval would be so unequivocal. 

54 The Architecture of Version 1 

Then, for an entire month, nothing happened. But, on July 10, the following email from 
Mechler arrived at CSEP: 

Volunteers, 

One of the members of SEEPP/E, Mike Davis, has taken our outline and added the good 
words. The attached, in text mode, is the result. I think I talk for the entire group that has 
been working on this when I thank him very very much. Now it is your turn. Please 
review and send me the changes by the end of July. We should be able to submit the 
FINAL product by the end of the summer. 

As you read each rule or at the end of a rule you will see statements with ??? attached. 
These were statements that Mike wasn't sure of, thought they were covered, or didn't 
know where to place. If you think they should be placed tell me where or they will just 
disappear. 

We are finally in site of the end. 

Ed 

There was no attachment, but the promised document arrived a minute later as a separate email, 
just over four single-spaced pages long. Version was now very close to what would soon be 
Version 1 (6. Appendix). There was a preamble (Introduction), seven general clauses (Rules) 
such as "Software engineers shall, insofar as possible, assure that the software on which they 
work is useful to public, employer, and user, completed on time and at reasonable cost, and free 
of significant error" and, under each general clause, between three and eleven more specific 
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clauses preceded by an "In particular, software engineers shall... " Each Rule had both a number 
(1-7) and a name in capitals (PRODUCT, PUBLIC, JUDGMENT, CLIENT AND EMPLOY ER, 
PROFESSION, COLLEAGUES, AND SELF). Each specific clause had a decimal number 
indicating its place under the general clause as a sub- rule. For example, the first specific clause 
under Rule 1 was 1.01 ("Assure that they understand fully the specifications for software on 
which they work"). The two decimal places allowed for the number of clauses under a Rule to 
grow beyond 9. At the end of all but section 3, 5 and 7, there were one or more (left-over) rules 
or phrases followed by "???". The first of these, for example, was "Assure proper privacy, 
accuracy". 

Given Mechler's favorable response, it is worth noting that I had not merely "added 
words". I had entirely reworked Version 0, keeping only a) the terms "Introduction" for 
"preamble" and "Product Development" (shortened to "Product") and b) the wording of 
provisions I did not understand or thought redundant or inappropriate. Mechler's other categories 
(and titles) had been abandoned and all the individual rules had been rewritten. Mechler had said 
he would like a code consisting of an "an intro sentence with bullets. Most of the ones [codes] I 
review[ed] were like this". The code he got had a more complicated structure. There were no 
bullets. Instead, I had (it seemed) followed the typical IEEE standard.^^ Each sentence bore a 
number, making reference easy. The Rules were not sinqiy introductDry sentences; they were 
the general clauses governing interpretation of the more paticular rules under the general rule 
and serving as a backstop v\ten no paiticular rule ^plied My chief innovation, the use of "In 
particular" before each list of particular rules, was intaided to stress that the particular rules were 
not all that a software engineer need be concerned about The general rule had to be considered 
too. 

My stmcture was no closer to that Weil had suggested ("put the inperatives in categories 
with rationale or preamble to each category")- The general Rules, though serving to categorize 
the more specific rules, were not mere rationales or preambles. They were (as the code called 
them) Rules. In this respect, as in some others, my document most resembled codes with which 
most software engineers would have been familiar. In general stmcture (and mariy provisions), it 
resembled the IEEE's Code of Ethics of 1979, the Code of Ethics of the Natiorial Society of 
Professional Engineers, and ABET' s Code of Ethics. 

Significantly (as it turned out), n^^ (version of the) code did not much resemble either 
IEEE's 1990 code of ethics or (except for its decimal numbering) the ACM's 1991 code. The 
IEEE had drastically shortened its 1979 code to a brief preamble and ten inq^eratives (such as "1. 
to accept responsiMity in making engineering decisions consistent with the safely, health and 
welfare of tte public, and to disclose pron^Dtly factors that might endanger the public or the 
environment"). The ACM's 1991 Code of Etiics and Professional Conduct, though a long code 
lite mine, was organized in a different way: an unusually long (six-paragr^±i) preamble, twenty- 
four "in^^eratives" (a little over a page long), and "Guidelines" inserted between the inperatives 
to provide one or more paragr^iis of guidance on interpretation of the inq^erative imrnediately 
above. The inq^eratives are divided into four categories: General Moral Inperatives (such as "1.1 
Contribute to sodely and human well-being"). More Specific Professional Responsihalities ("2.1 
Strive to achieve the highest guality, effectiveness, and dignity in both the process and products 
of professional work"). Organizational Leadership Inperatives ("3.1 Articulate social 
responsihalities of men±)ers of an organizational unit and encourage full acceptance of those 
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responsibilities"), and Compliance with the Code ("4.1 Uphold and promote the principles of this 
Code"). My code had many more imperatives than the ACM code had; it did not distinguish 
between (what the ACM's Preamble called) "fundamental ethical considerations" and "more 
specific considerations of professional conduct" (though it had a similar distinction between 
general and specific professional rules). My code did not make a point of the professional's 
"leadership role". In these ways at least my code could easily seem to anyone familiar with the 
current codes of the two sponsoring organizations to be a retrograde development a throwback 
to a style of code deliberately abandoned for something better. 

We might then have expected Mechler's reaction to have been more ambivalent than it 
was. Certainly, given the diversity of Mechler's little group, we would expect at least one of its 
members to question the code's structure. None did. SEEPP/E's reaction was as favorable as 
Mechler's. We can almost hear the sigh of relief. At last here is a draft code with which they 
could work. The structure was familiar enough that it did not get in the way of what seemed 
important: the particular requirements. One of the four SEEPP/E members who had had nothing 
to add to Mechler's list now responded in detail. That response (July 14), more than a half page 
long, came from Egypt (through Gotterbam's PRFCMP list). Among El-Kadi suggestions were 
removing "3.06. Decline to contract for a service with self. (?) ???", replacing the word "badly" 
in 4.06 with "not as excepted" or "inappropriate", and renumbering (and moving) 5.04 to 6.04. 
Norman's response, sent only to Mechler (July 20), was similar— with one exception—, though 
more than two pages long: Norman proposed one new rule: 7.04 "Endeavor to keep current with 
advances and changes in the field." 

5.5 Drafts, Drafters, and Draftees 

Eariy in August Mechler concluded that he had received all the comments he would 
receive (just two). He therefore emailed his "Volunteers" (August 8, 1996) the following (with a 
ccto Cabrera): 

Attached, in text form, is the final product of the SEEPP/E subgroup after adding your 
comments and eliminating ??? that were not necessary. If you have any outstanding 
additions etc., please let me know by the end of August because at that time I will submit 
it as our final product. 

This email brought a surprising response, a long fax (eight pages, single spaced). On August 17, 
I wrote: 

I guess I misunderstood your memo of July 20. I didn't realize you intended to do the 
final draft. I thought I would get the suggestions and incorporate them. I think this would 
be better for two reasons: 1) to keep the single style (a minor matter); and 2) to take into 
account suggestions Bernstein [sic] and Weil have made— and with which I agree (a 
more significant matter). I also had left some loose ends I wanted to clean up. I guess I 
should have put all this on email— like everyone else— but I didn't So, I'm now doing 
this fax to give you some idea of thinking here. 
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Following this introductory paragraph, there was a second explaining the two-and-half pages of 
annotations on the document that formed the second half of the fax. That document was not 
Mechler's "final code" but the one I had prepared largely independently, scavenging Mechler's 
"final code" when it arrived. I downplayed the differences. Except for "the change of an 'its' to a 
'the' in the last line of the introduction" and the addition of "endeavor" at the end of Rule 7, all 
changes were (I noted) in the subsidiary clauses and "even these changes leave more than 90% of 
the text unchanged." Y et whatever the similarities, the two codes did differ significantly— as the 
two pages of annotations comparing the "M" code (Mechler's) with the "D" code (Davis') made 
clear. What had happened? 

As so often during SEEPP's early years, there had been a failure of communication. I had 
just assumed that I would remain in control of the drafting. Though I had suggested that I would 
do only "one more draft", I had not actually said that I would do only one more— and I had not 
meant that I would do only one more. What I had meant was that I was ready to withdraw if 
Mechler thought I was getting in the way of software engineers doing what they wanted. But so 
far, the software engineers involved seemed to be happy with what I was doing. And I was 
enjoying myself immensely. I therefore had no reason to withdraw and so had not. I had, 
however, said nothing about this to Mechler. From what I had said, Mechler drew the obvious 
inference that he was lucky to get as much out of me as he had. Since he had a document with 
which he could work, he had worked with it, accepting Norman's and El-Kadi' suggestions 
whenever he could. 

Mechler also had not guessed that I was using IIT's research group to provide the sort of 
communal deliberation on the code that email had not provided. Since award of the grant in early 
1995, the research group— (primarily) Bumstein, Weil, and I— had been meeting almost monthly 
to go over SEEPP email, trying to understand the process. But, starting in June, once I had sent 
Mechler the first draft, Weil had begun convening meetings of the research group every week or 
two to go over the code itself. Each of the three members of the group seemed to come with a 
different purpose. Weil seemed primarily interested in understanding the code. Her questions 
were generally of the what-does-this-mean variety. When neither Bumstein nor I could answer 
the question, there followed a discussion of what the provision should mean. Once there was 
agreement on that, I revised accordingly. Bumstein, the only software engineer present, was 
concemed both to demand enough of software engineers to raise standards to a point she 
considered decent— and to avoid demanding so much that the code could not generally be 
followed. She could often state a problem with a provision (or the absence of a provision) 
without being able to offer appropriate language to fix it. She had remained silent online in part 
because she was participating in the research group's deliberations but in part because she could 
not on her own have offered "the words" and did not feel comfortable just complaining. Having 
worked alone on the code for almost two months, I was happy to have a responsive audience. I 
would take notes at the meeting, revise the code, and circulate a new draft tiie following week. 
What satisfied my two colleagues stayed; what did not was revised until it did. I had a resource 
Mechler lacked. 

Most of the IIT changes in the "D draft" simply clarified an existing clause or moved it. 
But five added new mles. Three of the new mles originated with Bumstein. Two of these were 
under Rule 1 (with older clauses renumbered accordingly): "1.01. Assure that specifications for 
software on which they work have been put in writing, satisfy the user's requirements, and have 
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the customer's approval" and "1.02. Assure that they understand fully the specifications for 
software on which they work." The other clause was 7.05 ("Improve their knowledge of the law 
governing the software and related documents on which they work"). The other two new lules 
were an atbenq* to explicate the irgunction against "self-dealing" (rather thaa as El-Kadi had 
suggested, sirrply dropping it): "3.05. Neither solicit nor accept a contract from a governmental 
body on which a principal or officer of their errqioyer serves as a member" and "3.06. 
Participate in no decision of a governmental or professional body, as a member or advisor, 
concerned with sofbA^are, or related documents, in v\Mch they, their enployer, or their client 
have a financial interest" I had found the inspiration for this ejcplication of "self-dealing" in part 
in the NSPE's code of ethics (II.4.d) and in part from studying of ASME v Hydrolevel (a case in 
which a volunteer participant in the standards writing process of the American Society of 
Mechanical Engineers seemed to have written standards designed to eliminate one of his 
employer's competitors).^^ 

In this way, two more of the "silent four" (Bumstein and Weil) made substantial 
contributions to the code. Only Jayaram and Sullivan did not Why? One explanation is that they 
resembled Bumstein in not being able to work alone. They might have made contributions 
sirnilar to hej:s had they been able to partidpate in the sort of face-to-face nieetings irr' s research 
group had They both think one or more face-to-face meetings would have helped the process.* ° 
Another possihality is that they saw others doing the work they would have done. They saw no 
reason to intervene. Both were evidently reading their email; they had responded, for exanqie, as 
late as April v\ten Mechler had asted for honie tovva Each had contributed his share to the early 
work, Sullivan by attending many of SEEPFs eariy meetings, and Jayaram by summarizing 
several British codes of ethics (ttough that contribution seems to have been lost in the ether). 
Jayaram certainly had said enough when things seemed to be on the wrong track (or v\ten he 
thought Mechler needed to know v\to chaired the Joint Steering Committee) . Now that the group 
seemed to be on the right track, Jayaram could read his email with delight 

5.6ABigMistate 

On August 20, 1996, 1 sent Mechler a distette version of the code. The covering letter 
indicated that vMle the code was identical to the one faxed on August 18, "you should have 
received a fax with this revision of M [Mechler^ s] 4.09, v\Mch I suggest [as] new 1.11, 
renumbering accordingly". This new 1.11 ("Assure that raw information used in software is 
accurate, derives from a legitimate source, and is used only in ways property authorized") would 
eventually prove controversial (as would most of the other late additions).* ' 

On September 11, Mechleremailedv\totwasnowfl/most Version 1, with a covering note 
two paragraphs long. After the salutation "Volunteers", he reports: 

We had some last minute suggestions; I have added and attached, in text is a copy for 
your review. Please do as fast as possible; if I do not hear from you by Sept 30'\ I will 
submit as our final product Please remen±)er each style is different 

Though this email is addressed to Mechler' s usual seven, the cc includes not only Cabrera (as 
was now Mechler' s custom) but Gottertem (v\Mch was reasonable, since Mechler was 
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technically working under him, but had not been Mechler's custom) and Keith Miller— a novelty 
requiring explanation. 

Mechler's explanation, given in the second paragraph, is: "Keith, Don forwarded a copy 
of your 'Testing, Reliability, and Trustworthiness' to me. After reading, I thought you may want 
a copy of our 'Ethics'." Miller's working group (Reliability and Safety) seemed to have been 
working more or less in parallel with SEEPP/E and had (it seemed) sent out its draft (two and a 
half pages single- spaced) on July 15 (with a revised version coming a day later)— denying 
Professional Competence (or SEEPP/E) the honor of reporting first. We will tell the story of 
Miller's document in Chapter 6.3. For now, what is important is Mechler's response. Miller's 
document arrived just as Mechler was completing the draft he would send out on August 8 (what 
I labeled "M"). Mechler had time to read, reflect on, and benefit from Miller's document. 
Mechler nonetheless acknowledges no debt to Miller. Miller's document suggested no revision 
in what would soon be Version 1. Mechler's only response to Miller's document seems to have 
been to send his own as a courtesy (as if he were leading a coordinate working group) or perhaps 
as an expression of pride (since he received Miller's document only because Gotterbam had 
forwarded it). While Mechler had to receive his copy through Gotterbam, each member of IIT's 
research group had received an individual email copy directly from Miller. Miller must have 
recalled that we were supposed to be observing the process as part of his working group. I used 
the document as a check against the code I was working on; I was pleased to find no reason to 
change what I had done. I did not wonder why I had no emails concerning its drafting.'^^ 

I sent Mechler two more (rmnor) changes on Sepben±)er 13. On Sepben±)er 30, 1996, 
Mechler emailed Cabrera and Gotterbam (with cc to each of SEEPP/E' s seven men±)ers): 
"Attached, in text format, for your review, is the final product of the SEEPP Ethics group. If 
there is additional work on this product, or ariy other part of the project, please contact us." 
Cabrera responded the next day with, "Thank you Ed"* ^ On October 4, Mechler took Cabrera' s 
couitesy response as an excuse to underscore SEEPP/E' s willingness to remain irwolved in work 
on the code (and to mate sure a change of email address did not exclude him) : 

Felipe 

Thffliks for the "Thanks e-mail" and CC to the group. Again if additional work is required 
we are available. Also, the product is available in other formats if you require a better 
version; it is held now in "Word". 

I have a new e-mail address 
emechlertSeri.eqtcom 

I will keep open the CompuServe one for the project for a while. The new one is under 
Exchange and as you know this is much better, except I need to get a book for various 
areas I can not get an answer for: too far ahead of total implementation. 

What is the status of the Joint Steering Committee and three task forces? When I read 
about this endeavor, it became very important to me. We really need to move in the 
direction proposed. Will the results be published? If you need any help, in any area, 
please contact. 
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Ed 

The same day this friendly note was sent, Dennis Frailey (the Joint Steering Committee's 
vice chair) emailed the (non ex-officio) members of the committee his comments on the code 
(with Gotterbam alone receiving a cc). Two days later (October 6), Cabrera accepted Mechler's 
offer of help: 

Ed, 

Could you address the comments made below [Frailey' s email without 
identification of author]? 

Some are tough and general and perhaps they cannot be addressed. Y et the more 
pointed ones would be nice to clarify and fix. 

Please let me know. 

— Felipe 

Frailey' s second paragraph set the tone of his response: 'Tn general I think this expresses some 
good ideas, but is entirely impractical in a number of cases. The problem is that many of the 
things being proposed are vaguely defined, impossible to accomplish, or not under the control of 
the software engineer. A few others might not be generally accepted as the 'right' thing to do.'"^^ 
Frailey had otgections to every item uriier Rule 1. After that, his criticisms were more scattered 
but still substantial. He seemed to have gone over the code with some care. 

The next day (October 7) Mechler received another email from Cabrera It began by 
urging Mechler "not to fed overv\telmed or disappointed but pleased that smart people are 
reading your document in a careful manner." It then asted him "to address" the points made in 
the email "below". Below was a forward from Mary Shaw, though Mechler could not tell the 
source from the version Cabrera sent him Cabrera had cleansed it of (almost) all references to 
men±)ers of the Steering Committee. Shaw too was unhappy: "I share xx' s general concern that 
this is fine in theory but hard to ^Dply. I realize that codes of ethics should be idealistic, but they 
also must be credible— that is, practitioners should be able to see how the code sh^:es their 
work Another way of saying this is that this draft seems a little naive."* ^ 

The attenpt to preserve confidentiality failed Mechler soon learned the identity of both 
critics. But the krDv\dedge was of little use. The two critics had votes on the Steering Committee. 
Though only one-sixth of the Committee's voting members, they might well be speaking for a 
larger number, enough perteps to defeat the code if it were put to an immediate vote. Mechler 
had no idea how the otters vvould vote. He had no choice but to respond to their criticism 

5.7 Mechler fights back 

Until now, Mechler must have seemed to everyone in SEEPP/E a gentle administrator, 
one v\to inevitably worted ty consensus, wittout strong ideas of his own He had known tew to 
bring a difficult undertaking to corrqietion, but te had stewn no deep understanding of v\tot 
SEEPP/E was doing. He had not otgected to ariything ariy SEEPP/E member had proposed His 
practice seemed to te to accommodate everyone. Even v\ten I, tewever unintentionally, 
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proposed to discard a draft code to which Mechler had devoted considerable effort, about which 
he must have had some authorial pride, and to which he had publicly committed himself, he had 
simply accepted my version of the code, letting his own die without a word of objection.^^ 
MecMer seemed ill-fitbed for debate with two stars of conqxrting, one a professor and the other a 
senior researcher (and adjunct professor) . What followed shows how hard it is to read character. 

Mechler probably should have taten time to allow his first thoughts to mature into a 
strategy. He should have consulted others, gathered evidence v\tere that seemed ^Dpropriate, and 
organized his response into a systematic analysis of the criticism, something academics could 
recognize as a decisive refutation. But email irMtes quick response (especially to critics who 
themselves seem to have responded quickly). Mechler did as irMted. Looking back with the 
advantage of half a decade, Mechler admits that "[w]hen I saw the comments I saw red. Not 
because people were commenting on the product, I expected that It was the comments 
themselves." They were lite the comments he heard v\ten he tried to introduce his conpariy to 
processes succes^ outside." 

Mechler responded to Frailey' s email on October 6 (the same day he received it), going 
through it item by item, inserting wtiat he had to say to a criticism right after the criticism. He 
did the same for Shaw' s on October 7. Frailey and Shaw had four distinct kinds of olgection in 
common. Much of the code was either 1) too idealistic (inpa::tical for ariyone), 2) too vague, 3) 
inpjssible for a software engineer to acconqiish (because not under her control), or 4) not v\tot 
some would think should be acconqiished. To these, Shaw added one criticism of her own (a 
criticism later revisions of the code would struggle to set to rest): 5) a failure to "discriminate in 
intensity". She also expressed a general distaste for the code's stmcture: "On the v\tole, I think 
the document would be more liMy to be read if it were shorter, crisper, and more realistic. A 
supplementary document could work through the exarrqies in a little more detail than the 2- 
liners that constitute most of this document' What she, one of the ACM-^Dpointed members of 
the Steering Committee, seems to have in mind is, of course, the stmcture of the ACM's new 
code of ethics (with its "crisp" two pages of rules and the longer Guidelines with their "exanqies 
in a little more detail"). Mechler, an engineer, had not yet seen the ACM code. He therefore did 
not see v\tot Shaw was getting at Since his own original conception of the code was closer to 
Shaw's "crisp" short code, he could only respond with a shmg: 'This is a matter of style. We 
decided on tte [NS]PE Code model to list some of the detail in items associated with the rule."* ^ 

Mechler' s response to the other criticisms that Frailey and Shaw made was more pointed. 
The critics were sinply wrong on all five counts. So, for exanqie, in response to the first 
criticism (good ideals but inpractical), Mechler noted that "the SE Code of Ethics was built 
using other professional codes as models. Ethics doesn't have a practical/inpa::tical side that I 
have ever experienced" Mechler agreed with Frailey and Shaw that a code of ethics should be 
practical, not a mere "ideal" (or aspiration). He disagreed only concerning the practicality of 
Version 1. Mechler' s method had (generally) been to go through other codes looking for ideas. 
Provisions developed in that way could not, Mechler supposed, be inpactical insofar as they 
were (more or less) the same as provisions in other codes that had proved themselves in practice 
(as evidenced by their long presence in those codes). Of course, in arguing this way, Mechler 
irr^idtly undertook to demonstrate that the code as a whole, or at least the particular provisions 
Frailey or Shaw criticized, were indeed in other codes— or had otherwise proved themselves in 
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practice. This he did not do .^° Neither Fiailey nor Shaw was liMy to tate a different view of the 
practicality of those provisions without such an explicit demonstration. 

Concerning the vagueness of provisions (the second criticism), Mechler had two 
responses. One was sinqiy to deny that a provision was vague. So, for exanple, Frailey 
conplained that "the last sentence of the introduction mates no sense to me: 'Each subsidiary 
clause is a specific ^plication of its general nile, one experience has shown needs express 
statement, but no set of subsidiary clauses exhausts the general rule.'"^' Mechler^s response to 
Frailey' s inconp:ehension is to offer (what he considers) the obvious gloss: "General disclaimer 
saying we cannot give all instances of a rule in ethics." Mechler^ s other response is more telling 
because it is more general: "Usually, ethics are vaguely defined" Every code must leave much 
room for interpretation Interpretation is inevitable. Direction to Version 1 on grounds of mere 
"vagueness" (as opposed to a specific failure to say something more clearly) is in fact an 
otgection to any code of ethics, no matter how long. 

Perhaps the heart of the case Frailey and SIhw rnade against Veraon 1 was that rnany of 
its provisions are inpactical for software engineers (however practical for other professionals). 
In some cases, the problem is that the software engineer simply does not have enough control of 
the process to do what the code asks; in other cases, the problem is that the cost of doing it is too 
high; and in other cases yet, there is no point to doing it. Frailey and Shaw can be quite specific 
about the impracticalities. So, for example, Frailey objects to 1.01 ("Assure that specifications 
for software on which they work have been put in writing, satisfy the user's requirements, and 
have the customer's approval") by asking us to suppose "you are brought in to fix something 
where you have (no) interface with the customer and do not know if the customer has approved." 
Mechler' s specific response is that "[the] example given is one of the problems we are trying to 
decrease the occurrence of." (This response must be read in the context of his general claim that 
"I don't think that any of the items are impossible to do as a professional") His point seems to be 
that all the rules under Rule 1 are introduced with "In particular, all software engineers shall, as 
appropriate" do as the subsidiary rules require. The code does not actually say that the software 
engineer in question must assure these things even when assuring them is impractical. Frailey' s 
example may well illustrate one of those situations where seeking to do what 1.01 asks is 
inappropriate (because the software engineer is in no position to do it). But even here, it would 
be good for the software engineer to at least try to do as 1.01 asks (for example, by asking for the 
specifications or for a way to contact the user or customer). Even when unavoidable, repairing 
software without knowing what the user needs and the customer wants is never good practice. 
"We" would like to have less of that. 

Mechler' s response to the fourth criticism is somewhat different. He begins by 
acknowledging the general point in a way that diffuses it: "I'll give 100 to 1 odds that under any 
professional code there are items that some will think are not the 'right' thing to do." Codes of 
ethics generally contain some provisions that "some" think not right. To criticize Version 1 for 
that is, therefore, no criticism at all, just a fact about writing a code of ethics. The question is not 
what some might "think" but what is "right" or, perhaps, what all but a few think right. 

That response, though sensible, does not actually dispose of what seems to be bothering 
the critics, that is, that Version 1 contains provisions they think "not right". So, for example, 
Frailey also objects to 1.01 because "I see no reason the ETHICS would require specifications be 
put in writing." To this, Mechler responds as he did to the previous objection: "at present[,] 
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writing is the safest way of assuring transfer of data." The code's Introduction explains that the 
particular rules are ones that "experience has shown need express statement". Rule 1 asks 
software engineers "insofar as possible, [to] assure that the software on which they work is 
useful to the public, employer, customer, and user [and so on]." If experience has taught 
software engineers anything about making software useful, it should have taught them to 
"document" (put in writing, whether on paper or in electronic form) as much as possible, 
including the specifications. That (according to Mechler) is why specifications are a matter of 
ethics. 

The disagreement between Frailey-Shaw and Mechler here may only be terminological. 
For Frailey-Shaw "ethics" seems to be general and uncontroversial (rather like what the ACM 
identified as the one- page "Code of Ethics"). The requirement to put in writing is something that 
looks too specific (and perhaps too controversial) to be "ethics" in that sense. It is more like an 
item in a "code of practice" (what the ACM code would put in later sections of its code— or in its 
Guidelines). For Mechler, however, 1.01 is not too specific or controversial to be in a code of 
ethics. Mechler, an engineer, had (at this time) not yet seen the ACM code. His paradigms were 
engineering codes. The NSPE code of ethics includes provisions that are no less specific (and, 
perhaps, no less controversial); that is also true of ABET's code (or, rather, of the combined 
Code and Guidelines). Mechler was therefore in a poor position to understand the terminology 
Frailey and Shaw took for granted. They, in turn, might have responded to Version 1 with more 
sympathy had they been familiar with the codes Mechler consulted. We have here a significant 
difference in "culture" (that is, in the ways of doing things taken for granted). 

Mechler' s response to the two critics was not totally negative, however. Shaw noted an 
"omission in the handling of intellectual property." But what she goes on to describe is actually 
much more than that: 

Piracy appears in 4.04, confidentiality and public domain IP are used inconsistently in 
4.05, copyright but not patent appears as a part of a list in 4.07, trade secrets and 
nondisclosure are mentioned nowhere at all (thought 4.05 was probably intended to 
address them), there's also nothing about export restrictions, and what there is about 
privacy is politically loaded. 

Mechler agreed to add "patent" to 4.07 (which at that time read, "Inform client or employer 
promptly if, in their opinion, a project is likely to fail, to prove too expensive, to violate 
copyright laws, or otherwise to turn out badly"). He also offered to add "export restriction" if 
Shaw would write the statement and specify its placement. But, "[as] for privacy being 
politically loaded, maybe, but from an ethical point of view we should be very aware of these 
conditions". He might have added that 4.07 actually says nothing about "privacy"— except in its 
catch-all "otherwise to turn out badly". That catch-all could equally well be interpreted to 
include "patent", "export restriction", and any other consideration that a client or employer 
should take into account before deciding whether a project should proceed. 

This brings us to the last of the five objections, the one only Shaw makes, that Version 1 
fails to distinguish between "absolutes" and obligations having less "intensity". Shaw seems to 
want a code of ethics to consist of "absolutes" (perhaps with another document providing the 
"aspirations"). So, for example, she says that she would "sign up to expecting an SE to refuse to 
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work on a practice that is blatantly unsafe or fraudulent." What she is not willing to sign to is 
expecting SE's to satisfy "this committee's view of good process". Mechler has the same 
problem with this objection that he had with the last. He cannot see what bothers Shaw: "I have 
never seen intensity associated Ethics: guidelines are statements to help judgment [and, for 
Mechler, the code is a set of guidelines]." If a project is '11319141/ something then I don't need 
a code: the code is for gray areas." For Shaw, it seems, codes of ethics state v\tot everyone 
knows to be a "bright line". For Mechler, the code should help draw lines in gray areas. The 
point of a code of ethics is to raise standards, not to leave them as they are. It is (in part) 
supposed to state a "view of good process". 

We could examine the debate between Frailey-Shaw and Mechler in considerably more 
detail. There is much of interest in the details. But we shall not because this exchange merely 
begins a debate that wiU continue until the code (by thea Version 5.2) is adopted three years 
later. We will have time enough to consider the issues first raised here— in their more mature 
form We must, however, draw two (tentative) conclusions now. The first is that the debate 
reveals a deep division between Mechler (and, presumably, the rest of SEEPP/E) and some 
members of the Joint Steering Committee concerning v\tot should (and should not) go into a 
code of ethics. The division does not seem to be between academics and practitioners. While 
Mechler !S a practitioner, the rest of SEEPP/E (except Norman) are academics (more or less) like 
Shaw; and Frailey (while a part-time academic) had many years experience at Texas Instruments 
and still held relatively high rank at Raytheon. The second conclusion is that the division 
between Frailey-Shaw and Mechler does not seem to be one between the "low minded" and the 
"high-minded". The economic welfare or social status of software engineers seems to have 
played no part in the debate (that is, no one has appealed to such concerns to defend their 
position). What seems to explain who is on which side of the debate, if any thing does, is a close 
identification with ACM (rather than lEEE-CS), an identification itself arising from an 
educational background in mathematics and computer science rather than engineering. The 
critics (so far) are ACM's representatives on the Steering Committee. They seem to have 
implicitly accepted the ACM's code as the ideal by which all other codes are to be judged." 

5.8 Gotberbam to the Rescue 

On October 8, about 8:40 AM, Mechler sent Cabrera a brief email (with the amusingly 
enant salutation "Feline"), offering his own guess about the origin of the Frailey-Shaw criticism: 

I tried to answer the concerns as best I could Hope it is OK. I think the change to a 
professional status will bring up this type of frustration from many people and maybe this 
individual is fighting it a little. I did not send niy comments to the group do you want me 
to? If there are additional comments lite these[,] maybe a meeting is in order to discuss 
the results. 

Apparently, Cabrera thought it a good idea to let SEEPP/E see the Frailey- Shaw-Mechler 
exchange because, at 1 1 : 33AM, Mechler emailed Cabrera again (the salutation now 'Tdipe") : 
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I feel in tune with the group after all the reviews and comments building the product. I 
will send both around asking if there are additional comments or areas requiring change. 
Will you give me a name for the reviewers to tell the group? Task Force Review Group, 
etc. Second review to follow tomorrow I hope.^^ 

Cabrem replied twenty rmnutes laten 

I am satisfied with your changes given that you are in tune with the whole group. 

I did send you a second e-mail (I believe yesterday) with more comments. 

I suggest that after you incorporate those comments, if you think it would be 
good you shodd drcdate tte docmnent by the group. Tliese issues are tough as so rnary 
people are affected by them 

Less than two hours later, Cabrera responded again: 'Task Force Review Group chaired by me is 
fine." So, it was Mechler v\to provided the name by v\Mch the critics would be known, giving 
them a status they would not have had as two individuals on the Joint Steering Commitbee and 
adding to the confusion some of the volunteers already had about how the Joint lEEE-CS/ACM 
project was organized 

The next day (October 9) Mechler sent Cabrera another brief email: "Sorry I spelled your 
name wrong in the first review ['Teline"]. I think the first commentator got to me a little; heard 
those responses too marry times in my life. It seems the ethics product has developed some heat 
in the total effort; I got four e-mails from Don Gotterbam but I will get to them after sending this 
reply." One of Gotterbam' s emails (dated October 8) was a page-long announcement (and 
ddailed explanation) of a listserv for the "Professional Conpetence Standards Task Force" 
(PRFCMP-L-Requesb(a)UrKVMl. UrK.EDU). Everyone else in Gotterbam's task force 
received one of these (or, at least, should have). Mechler responded with his new email address 
and (for good measure) phone number. The next email announced Version 1.0 to the working 
group, declaring that it was "developed by a sub group lead by Ed Mechler of the professional 
conpetence working group." The next paragr^ii solicited comments on the code [^jpended 
sevaBl paragr^iis below]: 

We are especially interested in distinguishing between those in^^eratives v\Mch are 
asprational and those v\Mch can be embodied in a code of practice. It would be helpful if 
your suggestions were accon^Bnied by suggested rewording rather than just sending a 
general suggestiorL Please ^Dply your special expertise to this. 

The paragr^±i immediately below announced there had been a suggestion "by one of their [the 
Joint Steering Commitbee' s] men±)ers that they review [the code] in NOVEMBER!! so your 
brilliant and r^d responses are encouraged" There was a "ps" announcing Gotterbam's belief 
that the 'list is back in service" and everyone's name is on it Between this letter and the code 
itself (unchanged from the week before) was a ten:p)rary address. From July 1996 through 
January 1997, Gotterbam would be at the School of Engineering and Applied Sciences, George 
Washington University. He would be using a GWU email address. 

Having read Gottertem' s emails, Mechler sent off one of his own to his "Volunteers": 
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Our product has been review[ed] by the Task Force Review Group chaired by Felipe 
Cabrera. Attached is the first review comments and my reply, again in text format. If you 
have any additional comments or disagreements with my comments[ J send them to me as 
soon as possible and I will pass them on. There appears to be a rush associated with our 
product so I would like additional comments ASAP. I will send the second review and 
comments in the next e-mail. Let me know if you get both. 

He then gave his new email address (as he had with Cabrera). He sent another email to the 
volunteers a few minutes later, his response to Shaw attached. 

Late that day, Mechler emailed Gotterbam. One of Gotterbam's four emails of October 9 
had offered to help with the response to Frailey and Shaw. Though it was now too late for that 
help, Mechler thanked Gotterbam and asked some pointed questions. Mechler wondered why 
Gotterbam had asked the working group to divide Version 1.0 into "imperatives" and 
"aspirational provisions". Was Gotterbam siding with the critics? Mechler also wondered 
whether he had missed something. Frailey and Shaw seemed to share a conception of codes of 
ethics differing from his own. If Gotterbam shared that conception, it was something about 
which he (Mechler) should know more. Gotterbam responded with his interpretation of events 
and suggested that Mechler have a look at both the ACM and IEEE codes.^^ The next morning 
(October 10) Mechler emailed the ACM and IEEE for copes of their codes. By 8: 36 AM, he had 
the IEEE code. It took him another hour before he was directed to the website from v\Mch he 
could download the ACM code.^ ^ 

The next day (October 11), Mechler sent GotteriDam the saniedocurnents (Ms answers to 
Frailey and Shaw) that he had sent SEEPP/E two days before. By then, Gotterbam also had— 
thanks to Frailey— received a copy of Frailey' s own comments (October 4) and Shaw's 
(October?)." 

5.9 Farewell Cindnnatus 

On October 14, Mechler received his first respjnse from SEEPP/E to his exchange with 
the Task Force Review Group, a brief fax from me. It began: 

I ergoyed your exchange with Cabrera Thought you did a good job, too, in dealing with 
his points. If I have ariyfhing worthv\Mle to add, it is that (in some cases) he didn't pay 
close attention to the wording, for exanqie, 1.01 does not require more than v\tot is 
"possible" and its subsidiary clauses that sg^y only as "^Dpropriate". 

My next (and final) paragraph asked a question: 'Discussion of 4.01 says 'I agree with Dermis.' 
Who is Dennis? We don't seem to have his message in our e-mail file!" (Though Cabrera had 
tried to purge the exchange of all references to men±)ers of the Joint Steering Committee before 
releasing them to Mechler, he had failed One reference to 'Dermis" had survived) 
Mechler emailed me the same day (October 14). He began by sharing ajoke: 
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I thought you would get a kick out of the two e-mails. I do not think anyone knows that 
you, etc are helping. It may be unethical but enjoyable, to answer the comments when I 
have two or three ethics experts helping. 

Of course, neither I nor any of the other experts had helped with Mechler's responses. But some 
had helped with the code (and all would doubtless have helped if asked). Mechler then gave his 
assessment of the situation, "I now think that some in fighting occurred but do not know what. 
Cabrera didn't write the reviews". Mechler now thought he knew what Gotterbam wanted. 
Would I have a look at the ACM code of ethics? "I'd like you to read it and comment; I have 
some problems with the approach." He then went on to ask why "you fax me instead of e-mail" 
and concluded by describing the state of his SEEPP/E files (which he had promised to the 
research group): "I have not transferred the e-mails to disc yet. Of course I started a new 
directory ".^^ 

On October 18, Mechler received another fax, again from me. Bumsbein, Weil, and I had 
m^ earlier that day. We had "decided on one editorial suggestion in last line of Introduction" 
(striking "one" and replacing it with "an application that"). We hoped that would "tate care of 
what one critic thought didn' t mate sense" . We had also discussed "how thin email discussion of 
our work has been so far." We had expected more "back and forth lite that between you and 
Cabrera". We also asted two questions. One concerned how much discussion Mechler thought 
had gone on "off our email site (beside n^^ faxes)". The other revealed we had either forgotten 
all about Miller' s email Quly 16) or rmsunderstood v\tot it was: 'Is our working group ahead of 
the others? Or did we just miss their reports?" I concluded with an expianation of my mysterious 
preference for faxes: 'If s easier for me: I know how to use fax-modem; email requires print out 
for secretary v\to then types it in again (or canying in a disk) ." 

Mechler responded a few days later (October 23) . He thought the proposed change in the 
Introduction was "OK". He would add that to the one change he had said he would mate in 
response to "the reviewer^'. He was still waiting to see if there would be airy other suggestions or 
comments. So far, there was nothing. He too had expected more debate. One of Gotterbam's 
emails had mentioned a Steering Committee meeting in November, but Gotterbam now said that 
it had been cancelled "I will have a meeting with Don next month, he will be in Pittsburgh, and 
maybe find out v\tot is next" Mechler thought there was a struggle over format "Were you able 
to get and read ACMs [code]?.... I think Don lites that one since he worted on it" Mechler did 
not know how the other SEEPP working groups were doing. But he had passed on to Bumstein a 
copy of the report (Miller' s) that Gotterbam had sent him He too would lite to know more about 
the state of "the entire program". He had asted a "number of people. . .but no answer." Peih^:s 
he would email them now. 

I faxed my evaluation of the ACM code on October 26. 1 had three comments: 

Frrst, it is, of course, a new code ( 1992) in an unusual format In this respect, it resembles 
the 1979 IEEE code that, after much boasting and a few years of use, was junted in 1990 
for a traditional format Whether ACM' s new format will prove another faiX or instead an 
enduring contribution to code writing, remains to be seen On the principle of engineering 
conservatism alone ("avoid fads"), I think we are justified in staying clear of it for a 
decade or two. 
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Second, the ACM's code's format could not easily be imposed on what came out of our 
e-mail deliberations. What we produced was, in essence, a combination of ACM's 
"General Moral Imperatives" (some of which, I hasten to add, seem more controversial 
than "moral imperatives" should be, e.g., "give proper credit for intellectual property") 
and the more specific imperatives in sees. 2-4. But our system of organization strikes me 
as more useful than ACM's. The big difference between the two codes is that the ACM's 
has "Guidelines" and ours does not. I think the idea of Guidelines— or, more exactly, a 
commentary— for the Imperatives is all right (though nothing yet suggests we need one). 
But the actual Guidelines do not strike me as very informative, certainly not informative 
enough to justify the space they take. So, I say that, inch for inch, our code [is] 3 to 5 
times more useful (and user friendly) than ACM's. 

Third, that's my opinion based simply on looking at the documents. It is, however, not 
my opinion alone. The two CS faculty at IIT who have used both the old ACM code and 
the new in teaching both prefer the old for convenience, clarity, and simplicity. So, I 
think we were wise to go our own way. 

This response must have chimed with Mechler's thinking, but we have no record of a 
response. Indeed, from here on, Mechler's records tell us very little. There is an email on 
November 8 from Mark Kanko, Major, US Air Force. He had taught a course in the Department 
of Electrical and Computer Engineering, Graduate School of Engineering, Air Force Institute of 
Technology, Wright-Paterson Air Force Base (just outside Dayton, Ohio). He had used Version 
1.0 in class, asked his students for comments, and thought their comments might help with 
evaluating the code. Kanko had contacted Gotterbam the day before and Gotterbam had 
suggested he contact Mechler as well. Gotterbam and Mechler met for the first time on 
November 18 at the Software Engineering Institute. They ate lunch between classes Gotterbam 
was teaching (and having taped). The next day (after many days of back and forth testing 
protocols), Mechler seems to have received Kanko' s student comments as an attachment ("As I 
started to read, I wondered whether you would like responses"). (We will consider the student 
comments in detail in 6.7.) 

Mechler also wrote Gotterbam, Laurie Werth, Kanko, and Norman ("Subject: FW: Ethics 
Workshop") on that day (November 19): "I had trouble through the Multiple Recipients site; host 
not found. I decided to form my own list with members I know of. Please one of you send this on 
to the rest and tell me the correct address of the list." Less than two hours later, Norman 
responded with some comments about the ethics workshop: "Plan on it for 1998, not 1997." 

Mechler's last email from Cabrera arrived on November 25, 1996. The email consisted of 
the "action items" adopted during the Joint Steering Committee meeting held on Thursday, 
November 21. (This was the meeting Gotterbam had thought cancelled. In fact, all that had been 
cancelled was the participation of ex officio members.) Mechler wrote back thanking Cabrera for 
the minutes, saying how sorry he was that he had not known of the meeting in advance since he 
would have liked to have met Cabrera (who lived in Seattle). Mechler also mentioned his 
meeting with Gotterbam the previous week. Cabrera wrote back: "I am SORRY, this was 
supposed to go to Robert Melford. Now you ALSO know all the action items that came out of 
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the meeting." Almost exactly a year after he seemed, like an Old Testament prophet to come 
from nowhere to save Gotterbam's working group (and SEEPP) from failure, Mechler's 
participation in SEEPP' s work had all but ended. We must now consider what else happened in 
1996 and how that prepared the way for the very different, but equally important, achievements 
of 1997. 
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5. Appendix: 
VERSION 

OUTLINE: 

INTRODUCTION 
SYSTEM DEVELOPMENT 

Evaluate business affects and culture changes 

Implement Ethical evaluation. 

Assure proper Goals and Objectives 

Assure proper Development Methodology 

Assure proper Project Management 

Assure proper testing, debugging, Case Tools , GUI, etc 

Only approve safe and accurate documents 

Assure proper privacy, accuracy, property, access and people 

Assure proper estimates 

Assure specifications are fully understood 

Assure environmental issues addressed 

Promote max productivity and min costs 

PROFESSIONAL PRACTICES (Himself/Herself) 

Accept responsibility in engineering decisions for safity, health and public 

welfare; disclose endangering/abusive factors, 
results must be judged from the standpoint of society as a whole 
meet changes as they occur, 
departure from the norm can be justified 
define "usual circumstances" should be a matter of 

professional judgement, 
understanding of broad fundamentals, 
neutrality in preparation 
not serve a special interest 
professionalism is to put the public's interest 
ahead of self interest 

Put forth best effort 

Show inicitive on projects 

See through to successful finish 

Don't try to do it all yourself 

Don't ignore signs of trouble 

Don't dodge the issues 

View matters from others points of view 

Accept full responsibility 

adequate technical training and proficiency 
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independence in mental attitude 

Due professional care 

adequately planned and supervised. 

Present fairly 
Professional skepticism 
Establishment of Quality Control policies and procedures. 

Avoid conflicts of interest; disclose. 

Reject bribery. 

No paybacks from contracts 

No political contributions, gifts, commissions, etc. for award of contract 

Not accept outside work detriment to regular work 

Not represent adversary interest without consent 

Do not use employer equipment on outside engineering 

No pirated soft/etc 

Respect ownership 

Service only in areas of competence 
Faithful agents or trustees 
Non-association with fraudulent businesses 
Signature to only areas of competence 
Same project-one party pay only 
No decisions on services provided by self 
No promotional efforts without consent 
Salary appropriate to professal qualifications 

Honestity in stating claims. 

Objective and truthful public statements 

Avoid deceptive acts 

Not reveal confidential facts 

Not falsify or permit misrepresentation 

Admit own errors 

Avoid misrepresentated statements 

Responsibility to detect and report errors and irregularities 

No professional compromised 

Not promote own interest at expense of profession 

Constructive service in civic affairs 

Extend public knowledge of engineering 

Prepair articles 

Avoid fads 

Develop ethical check lists 

Develop review process 
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Develop contingency plans 

Assure data is accurate and legitimate; kept confidentiall; 

authorized use 
Customer fulfillment 

Recognize and report problems to proper authorities, cooperate 
Inform client if project will fail 

PROFESSIONAL OBLIGATIONS(Others) 
Improve understanding of technology. 
Improve technical competence. 
Improve ethical education 
Develop ethical learning 
Assist collegagues in professional development. 
Advance professions integrity and prestige 
Support the Code 
Obey the laws of the country 

Not review work without other engineer knowledge 

Honest criticism and credit properly. 

Treat fairly all persons. 

Avoid injuring others by false action. 

Assure employee informed 

Not attact engineer falsly 

Assure only qualified signatures from others 
Assignments only by educated/experience 
Develop positive agreement on ownership 
Assign duties to utilize for potential 

Assist in development of Organization ethical environment 
Assure commitment 
Assure employees know 

Policies and procedures 

to protect passwords/files/soft/hard 

to cooperate with proper authorities 

to work in cometent areas 

to state opinion vs fact 

Assure employers and supervisors know of code of ethics 

Voice concerns 

Don't supplant another engr after steps have been taken 

for employment 
Fair and just compensation 
Never invade another divisions domain without knowledge 
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Give fair hearings 

Don't prevent better opportunity elsewhere 



NOTES 



^ Interview of Mechler, June 1 1, 2002. 

^ Mechler filed the January 1995 CFP with his other (p^:er) SEEPP documents. 

^ Mechler' s archive E950302A. 

^ Mechler would later join the Engineering Manager Body of Knov\dedge Task Force 

(EMBOK), though it never (as far he knows) "got off the ground". October 21, 2003 email 
(Sutgecb Ch^Dter 4). I have found no record of a task force with that name. 

^ Interview of Mechler, June 11, 2002: "it really wasn't a planned idea . .the opportunity 

was there and I junq^ed on it I said, 'Why not?' If we build it up in such a way, and we put tte 
things in there that we think. . .should be ethical issues— we might be stretching ethics— but if 
you say that you shouldn't accept kickbacks, whaf s the difference in saying, 'Well, you should 
follow the process to get the job done.' . . .most of the software people, aid the people that were 
loading the software, building the software, testing the softwa:e, had no idea of einy process. 
Theyjustdidit" 



Mechler' s Archive, E950313 (Tipton); E950313A (Bariscd). 
Mechler' s Archive, E950313A. 
Mechler' s Archive, E950421. 
Mechler' s Archive, E950425. 



GotteriDam could not have learned of Mechler much before June 10 since a) he did not 
imlude Mechler on the list of volunteers he sent out on that date and b) he had not yet included 
Mechler in the prof conp list he used on that date. 

'' Mechler' s Archive, E950610; E950610A. 

'^ Interview of Mechler, June 11, 2002. The late date he joined (March 1995) explains both 
his absence from all the early lists of volunteers and his sense of SEEPP' s size and organization. 

'^ Mechler's Archive, E950629. 

'* Neither Mechler nor ariy other volunteer seems to have written a statement about v\tot 
the codes said about conpetence. GotteriDam had, however unintentionally, reverted to the failed 
strategy of "divide and conquer" (accepting the division of labor between working groups). And, 
as before, it failed 
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^^ Mechlei' s Archive, E950701. 

^^ Mechlei^s Comments on Ch^Dter 4 (October 31, 2003). Presumably, the deadline he is 
referring to is the date for the November 1995 meeting of the Joint Steering Committee. But I 
can find no mention of that meeting date in smy of the June or July memos. 

' ' Mechler^ s Comments on Chapter 4 (October 31, 2003). 

' ^ Interview of Mechler, June 1 1, 2002. 

'^ "I also understand fromjayaram that Mario thinks we are working on the project* that is 
why he is cc." (December 4, 1995) 

^ ° The email was actually sent (and received) on December 6. In those days, I wrote emails 
as if memos, leaving it to CSEFs secretary to turn the memo into email, often losing a day or 
two in consequence. 

^' Again, it seems to have been Jayaram who told Mechler that Cabrera had replaced 
Barbacci as chair (when Barbacci had become lEEE-CS President): "Do you have an e-mail 
address for Louis- Felipe Cabrera? I [Mechler] will send him of [sic] of a copy of what we have 
been doing and see where he wants to go. I assume you will still work with us even if our leader 
will not." Mechler' s Archive, E960319A (email to Jayaram). 

^^ The three contributors Mechler may have intended would be El-Kadi and Jayaram, each 
of whom had done some code summaries Mechler may have seen, and I, who had made a few 
suggestions. Mechler (E960708), a note to Norman a few months later, confrms the small 
contribution of even these three: "You have contributed more than half of the small group. Only 
three have contributed. My next message will point this out. Of course the small group has done 
at least a million times more than the large group." Mechler was politic enough not to point out 
in his "next message"— or in any other he sent to his volunteers— how little they were doing. 

^^ See, for exanple, March 20, 1996 (in an email to Jayaram with cc to rest of his 
volunteers): "I am cc this message to the remainder of our new sub-task force SEEP[P]/E (lite 
the name? - no imagination). . . .1 am also sending it to the SEEPP/E because your excuses." The 
single P in the first use seems to be atypogr^±iical enor 

^* Mechler^ s reasoning turns out to have been sinqie 'The reason I wanted you to write the 
good words, Mr. Jefferson, was that I thought all the [other] participants were software 
engineers." Email: October 31, 2003. 

^^ The eariiest of these was "The Moral Authority of a Professional Code", Authority 

Revisited: NOMOSXXIX (New York University Pr^ss: New York, 1987), pp. 302-337. 
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^^ The most inpoitant of these are: "Thinking lite an Engineen The Place of a Code of 
Ethics in the Practice of a Profession", Philosophy and Public Affairs 20 (Spring 1991): 150-167; 
and Michael Davis, "Codes of Ethics, Professions, and Conflict of Interest: A Case of an 
Emerging Profession, Clinical Engineering", Professional Ethics 1 (Spring/Summer 1992): 179- 
195. 

" "Civic Virtue, Comiption, and the Stmctuie of Moral Theories", Midwest Studies in 
Philosophy 13 (1988): 352-366. 

^^ Some years after this event, Gottertem asked me v\^ I had not chected with him before 
accepting Mdcher' s offer. I had no clear memory but I did have the inp:ession that Mechler at 
least had Gotterbam's tadt ^Dproval. Mechler had used Gotteatam's distribution list to send 
several messages, and had included Gotteibam on some others, all without ari^ otgection from 
Gotterbam 
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Fax (Gottertem to Davis), December 1, 1997 (Archive). 



^° GotberbamWolunteersWembens 1995 (6/10/95) as well as Gotterbam\SEEP 
VOL_10_94. Omitted from this June 1995 list are: IIT's three (Bumstein, Weil, and me), 
Mechler, and Sullivaa Gottertem seems to have begun updating the June 1995 list a few days 
after returning from England See Gotterbam\94r96 Misc, for the various working group lists 
including "PCOMPENT-WG list" (file date February 21, 1996). 
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See Gotteatam email to Davis, June 5, 2003. 



^^ For those who find Gotterbam's forgetting Jayaram's location implausible, it is worth 
pointing out that Mechler' s April 10 email records an even more implausible oversight that 
Mechler himself committed (and admitted): "I should have thought of this eariier. I could have 
visited Bumstein [in Chicago] and Sullivan [in Washington] and I don't even travel that much." 
Since Mechler knew (in some sense of "knew") that Bumstein was part of IIT's research group, 
he should have realized that she was in Chicago just as the other two members of that research 
group were. But he did not realize it. Apparently, he made the same sort of mistake Gotterbam 
did. 

^^ How many days later? The only documentary evidence suggests that the date was at least 
a month later (much later than my memory suggests). On May 1, 1996, Weil wrote Mechler as if 
she did not know that I was to work on the code: 

The starting and stopping is exasperating but I hope you will not drop the project. At the 
moment you have a good list that has to be organized— that's what I meant by 
"categorized" weeks ago. Some injunctions have to do with competent and responsible 
work, "put forth best effort;" others have to do with customer, etc. A preamble about 
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computer engineering and developing programs is needed to give an organized list some 
context. I hope these comments are of use. 

Mechler's response the next day (May 2) is worth quoting in full: "It is EXASPERATING but I 
think necessary. I will not quit until someone says so and after a fight. Thanks for the input." 
May 2 was the same day he wrote reminding me that I had said I "would add the 'good' words' 
to the ethics outline". 

^ Mechler Archive, E960325. It was Mechler v\to informed me of Vivian' s contact (in a 
way that did not register at the time) . See E960326, March 26, 1996: "Also Vivian has suggested 
a form for the ethics project and I have invited her for lunch to discuss; told her to see you. I 
forgot you two are at the same place." 

^ ^ My original (handwritten) response given to the secretary for sending had the "O.K." as a 
question. The question mark was lost in transcription. 

^^ The question of sending distette versions arose because CSEP was having trouble 
receiving large attachments at this time. The cause may have been either that CSEF s electronic 
mailbox was too small (and some large messages just never arrived) or that the program CSEF s 
secretary had to use to open attachments (PINE) was too conqiicated for her. CSEP was then 
having both sorts of problem 

" As if to add to this confusion, the same email— 'Distette (with a somev\tot revised 
version of code you saw is in mail)"— was sent again on July 19 (E960719) and withdrawn a 
minute later (E960719A). 

^^ In fact, I had by now forgotten Gottertem's emails of the year before. I was sinply 
following the ordinary practice of legal codes. 

^^ For details, see Paula Wells, Hardy Jones, and Michael Davis, Conflict of Interest in 
Engineering (Kendall/Hunt: Dubuque, 1986). 

*° Interview of Sullivan, October 10, 2002; Interview of Jayaram, Febmary 25, 2003. 

* ' Lite most of the other late additions, this was Bumstein' s. 

^^ Conpare Mechler' s comments (November 1, 2003): "shortly after the first version [of the 
Code] was released we received an e-mail, 'that might interest US', about one of the other 
subgroups [Miller^ s]. It was good work but we couldn't detemdne how to place it into our work 
at that time. The other subgroup was somev\tot related to the original eight working groups but 
we thought we couldn't use their work at that time. To this day, we do not know v\tot h^:pened 
to their work" 

^^ Mechler archive, E960930. 
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^ October 6, 1996, p. 1. 

* ^ GotteibamWension (AAC0DE4, p, 1 
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Mechlei^s September 11, 1996 memo treats ni^ revisions as just another set of 
suggestions: "We had some last minute suggestions; I have added and attacted" 
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October 31, 2003 (Sulgecb Ch^Dber4). 
GotteibamWension 0\ACODE4, p, 2. 

October 6, 1996, p.4. 
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That is, the email to Cabrem did not go through Version 1 provision by provision giving 
the source for each. Mechler would provide such a provision-by-provision analysis to Gottedem 
a few months later. SeeCh^DberT. 

^ ^ Shaw is a hat gentlen "The last sentence of the second-order bullets being inconplete sets 
of exanqies is pretty obscure"— but, it should be noted, not so obscure that she did not 
understand it Gotbeatam' s Archive, Version 0, AC0DE4, p. 2. 

^^ See, for exanple, Mechler^ s response to Shaw (October 7, 1996): "The question is. 
Where does responsiMity begin? It must start at the SE Professional. I think too much 'Thou 
shall nof or 'Ttou shall' is being read into the Code' s Items. They are guide lines." 

" This is the interpretation I now give this debate, knowing wtet. I do of the authors of the 
critidsm The inp^ssion we at IIT had at the time was quite different Weil' s official report to 
NSF Quly 21, 1998) gave this interpretation (Report on Grant ^©523650): 

There followed comments from the Chair of the Task Force Review group, v\to criticized 
the draft for vagueness, for requiring the inpjssible or v\tot is outside the control of the 
software engineer, and questioned the basis for ariyone outside a con^Miy or its 
managers defining ^Dpropriate behavior for software engineers. The comments were 
presented together with replies by Mechler, v\to remarted on the "bleak outlook" 
reflected in the conmients. Ife handled a second set of siniUar conmients in the sarm way . 
As more comments came in critical of "soft, qualitative language" and the lite, they 
^Dpeared to reveal a division between the perspective of academics (members of the WG) 
fflxi the perspectives of practitioners (contributors of comments) . 

In fact the Task Force Review Group consisted of two men±)ers, one an academic and the other 
a practitioner-academic. Mechler' s group may actually have had proportionally more 
pr^tioners (depending on v\tot counts as a "unit practitioner"). Whatever the cause of the 
disagreement it does not seem to be the same as reported irt Stuart Sh^ro, 'Degrees of 
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Freedom: The Interaction of Standards of Practice and Engineering Judgment", Science, 
Technology, and Human Values 22 (Summer 1997): 286-316. 

^^ If "second review" means the response to Shaw, this phrasing must be a slip of memory 
orpea MecMerseerris to have sent out that response the day before. 

" These emails seem not to have survived We know about them through Mechler^s email 
to me (October 14, 1996): "Don wanted to help me answer but one was sent and the other was 
being sent v\ten I receive his e-mails. . . .1 think I finally found out v\tot Don may have wanted" 

^^ Note that this is Mechler^s first contact with the ACM code even though he 
seems to have "asted for" that code as early as December 4, 1995. Had it become 
easier to get the code (or had Mechler' s methods irrpoved with Gotterbam' s advice)? 
It is also interesting that he now asked the lEEE-CS v\tether it had a code of ethics of 
its own and learned several days later (October 14, 1996) that it did not Even after a 
year' s irwolvement with SEEPP, he was cleariy not an "insider". 

" GottebamWersion l\DFCOMMENrS (October 4, 1996); GotterbamWersion 
IVCMTTVIARY— 1996 (October?, 1996). 

^^ By this time, Mechler also knew "Cabrera didn't write the two reviews but two people, 
Dennis and Mary [did]." 
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Chapter 6: The High Pditics of 1996 

"Politics is not an exact science."— Otto von Bismarck (1863) 
"Politics is not a science... but an art."— Otto von Bismarck (1884) 
6.1 Meeting Rogerson 

While Mechler's SEEPP/E was writing Version 1 of the code of ethics, SEEPP's other 
activities continued. Occasionally, they intersected with SEEPP/E's; more often they did not. 
Their story reveals both the importance of what Mechler accomplished and some of the political 
problems that accomplishment bypassed or produced. SEEPP's activities in 1996 also help to 
explain why Melford resigned as co- chair at the end of the year, why Gotterbam became the sole 
chair of a reorganized SEEPP, and why— the next year— the new SEEPP produced Version 2, 3, 
and 4 of the code. 

On January 27, 1996, Gotterbam received an email from Steve Barber whose help he had 
asked in recovering "the changes we made [in the SEEPP Task Force 'Guide to Operations'] at 
the 3/95 meeting in D.C." The computer that the "recording secretary" (Miller) had used to 
record the minutes had later failed, causing the minutes to be lost.^ Barber had applied a UNK 
"diff prDgiam" to conpaie the February 1994 draft of the Guide with the document Gotterbam 
emailed on February 22, 1995.^ Apparently, Gotterbam still thought the Guide inpjrtant enough 
to deserve this attentron. 

The first two d^s of February, 1996, Gotterbam was in London for PASE '96. ("PASE" 
stands for "Professional Awareness in Software Engineering".) The conference, though a one- 
time affair, was a sign that understanding software engineering as a profession was not a mere 
American eccentricity. It was Gotterbam' s attendance at this conference that provoted Jayaram' s 
angiy email. But, more inpjrtant now, it was at this conference that Gotterbam met Simon 
Rogerson (v\to was there to give a paper). 

Rogerson received a BSc (Bachelor of Science) in conpjter science from Scotland's 
University of Dundee in 1972. He worlsd in industry for twelve years, at various levels, on 
scientific and commercial management systems. He was Corrpjter Services Manager for Thom 
EM v\ten it annourced a nx)ve to a part of England in v\Mch he did not vvant to live. He decided 
to change careers. Because the government was then (1983) trying to bring instmctors with 
industrial experience into technical universities, Rogerson soon found a lectureship— at Leicester 
Polytechnic, an hour train ride north of London. The Polytechnic became De Montfort 
University a few years later (as part of a general enhancement of technical education in 
England). There Rogerson remained, adding ^plication-oriented courses and maintaining links 
to industry ty consulting. His industrial experience led him to see "social resp)nsitality" as a 
necessary feature of doing software the right way. In 1995, he helped to fourri De Montfort s 
Centre for Conpjting and Social Responsihality (CCSR) and became its first director Rogerson 
did not consider himself an engineer, not even a software engineers 
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In the UK, the standard job titles are "apphcations programmer", "systems analyst", and 
"information systems programmers". Computer scientists are interested in the science of 
computing rather than the application. In the UK, software engineers are interested in 
building robust systems according to engineering principles. They are more technically 
oriented than I am. (I think the same is true in the rest of Northern Europe, though 
perhaps not in France.) If I had grown up in the US, I might answer differently. I'm an 
applications person— and, in the US, someone who works on applications is a software 
engineer even if he is, as I am, more interested in the way people and programs react than 
in the technical qualities of the applications.^ 

By 1996, Rogeison was not only CCSR' s Diiecboi) he was also (officially) a member of 
several SEEPP working groups, including Gotbeibam's owa Not having heeoii much about 
SEEPP since he sent in his ^plication on October 19, 1994, he asted Gotbedem v\tot was 
h^Dperdng. From v\tot Gotbeibam said in response, and from what Gotteibam said in his two 
piMc talks, Rogeison concluded that 'loth Don and I were gi^Dpling with problems of creating 
the proper culture for good programming". He therefore invited Gotbedam to spend a semester 
as a guest of CCSR Gotbe±iara then planning a sabbatical for the academic year 1996-97, 
accepted* 



6.2 Tiy, ty again 

A few days after PASE (Febmary 16, 1996) and in another dty (Philadelphia), SEEPP— 
or, to be more exact, Gotbedem, Mdfoid, Ba±er, and Miller— met from 8 AM till noon during 
the ACM-sponsored Corrpiter Science Conference. All the SEEPP men±)eis present knew that 
SEEPP had missed its dradline. To this bad news, Gotbeibam added more. He had tailed to 
Frailey, the Joint Steering Commitbee's vice chair According to Frailey, ACM was increasingly 
unh^Dpy with the v\tole joint project The other two task forces had also missed the Noven±)er 
deadline. The v\tole three-footed project seemed much larger, indefinite, and difficult than ACM 
had anticipated Unless the task forces made significant progress soon, ACM might desert. How 
the lEEE-CS would respond to ACM's desertion was anyone's guess, but it was certainly 
possible that lEEE-CS would do as ACM had Frailey advised devdoping a "detailed schedule", 
realistic but strict, to hdp get the task force worldng again He wanted something he could show 
the ACM Coundl v\ten someone conqiained that nothing was happening.^ Gotbertem also 
"distributed a p^:er [he] had written conparing the work of several professional sodeties."^ 

By noon, GotieriDam had a rough draft of a schedule. After polishing it, he sent the draft 
to Miller for comment (Febmary 21). On the same day, he wrote a letter to "Messrs. Cabremand 
Frailey" describing the acconqiishments of the Philaddphia meeting and requesting money for 
two conference calls, for a meeting in the fall (at Brookings in DC), and for hiring a "single 
skilled writer", or "scribe", to assemble the documents the working groups devdoped into a 
"single document". Miller would be the scribe: "He is a practicing software engineer v\to has 
had contacts with NASA and published widdy on software testing. He is a urdvensity professor 
teaching conpjter sdence and working in the area of conpjter ethics." Gottertem describes the 
document Miller would produce as "standards of practice, standards of conduct, and standards of 
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ethics". Gotterbam also described what would happen once the document was drafted. There 
would be a review process involving "one or two people from each of the societies' boards". 
After revisions, "we would like to follow a process that was helpful in developing the ACM 
Code of ETHICS and Guidelines for Professional Conduct. .we would like to submit the 
document to the membership for review and comment by publishing it in the Communications of 
the ACM and in IEEE Computer." Gotterbam explained the need for a funded face-to-face 
meeting in the fall by noting the absence of any conference that all would normally attend and 
adding: "E-mail, unfortunately, is a very sterile medium for the creative exchange of ideas. (It is 
also very easy to procrastinate if E-mail is the only means of communication.)"^ The Steering 
Commitbee did not ^Dprove the budget request 

Qn March 3, 1996, Gotbeibam emailed the revised schedule to "SEEPP work group 
leaders" (and to Little and me) "for comment"— using an SEI listserv (se-ethics(a)ser.cmLLedu). 
The introductory paragraph declares: 

Bdow is an expansion of the detailed schedule v\Mch we developed at our meeting in 
Philadelphia At the meeting, I indicated that I would lite to micro-manage the project for 
av\Mle, so please send me copes of the items marted with an asterisk. I am sony for the 
short tum around this week, but I am leaving the country for a week on the 9^* of March, 
and I do not want to delay things because of my travel. We have the plan and once we 
start; to follow it interest in and support for the project will start; to increase. Best regards, 
don. 

The first three items provide a good sarrple of the v\tole schedule 

*Marchl: 

Send a "hello message" to your working group; M them know that we are about 
to start and thank them for their continued interest in this proj ect 

*March4r6: 

Develop material specifically foryour work group v\Mch: 

1. contains a statement of purpose for our task force (distributed to you on 
disk at meeting) & a straw man copy of the purpose of your working 
group. Invite comment from them on this. 

SEEPP Purpose: 

Software engineers make value- laden decisions that affect health, safety, welfare and 
environment. Standards and principles of ethical and professional practices will guide 
software engineers making these decisions 

SEEPP Scope: 

Standards, guidelines and recommended practices of ethical and professional practices 
for software engineering 
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2. Explain the difference between standards of ethics, standards of conduct 
and standards of practice. Request their input about issues in your working 
group's domain which fit any or all of these types of standards. They need 
not worry about which category to put them in. We will take care of that. 
See 3 below. 

For example: 

Most professions distinguish between standards of ethics, conduct and practice. These 
standards include a range of statements. Standards of ethics are generally broad and 
aspirational and do not prescribe specific behaviors— prevent harm. Standards of conduct 
are more specific and standards of practice are regulative— do not release a product 
which has not been adequately tested. Violating this later type of standard is generally a 
foundation for legal action. These three types of standards exist for people as members of 
a profession, employees, and as individuals. We are looking for a range of statements and 
examples of these types of standards as they apply to professional competence, (my 
working group). Please send any examples of these you can think of. They can be one 
line statements or paragraphs. We are trying to brainstorm the standards on email. I will 
organize your contributions and circulate the organized list to all of you for further 
comment.^ 

March 8 

Don will put his two cents in to coordinate all these materials that you have sent 
and share other^ s insights among work group leaders. If you do not hear from him 
by the 8f\ he probably has nothing to say. Proceed to Marh 15* task. 

The schedule ends thirteen items (and seven months) later with, "Oct. 15 [1996]: Latest revision 
from scribe to Don and Bob. Begin discussion of materials with joint committee." 

This email may leave one of two impressions. The first is that it is just another of 
Gotterbam's schedules, indeed, one with fewer prospects of realization than the others because 
the first of the deadlines, March 1 ("hello message"), was two days passed by the time the email 
went out. Was the schedule merely a device to buy SEEPP a little time? Time for what? The 
message does nothing to clear up the relation between what Mechler was doing and what the 
other working groups might do. Indeed, it says nothing about Mechler's group (and Mechler was 
not to receive a copy). Gotterbam shows no intention of adding Mechler's SEEPP/E to the list of 
working groups. Yet, given what Mechler's group was doing, it did not fit neatly into 
Gotterbam's Professional Competence working group (or into any other); SEEPP/E's work cut 
across the domains of the other working groups. The plan for eight working groups that 
Gotterbam had announced as "written in jello" had (it seems) long since hardened into concrete. 

The second impression this email may leave is that Gotterbam had learned something 
from Mechler, though not enough. While Gotterbam is still trying to get the working groups to 
develop purpose and scope statements first, he has also begun to think of the process to follow 
the preparation of those statements as less formal (much less formal) than he had earlier. He is 
now advising his group leaders to collect standards from the group, to "brainstorm", not 
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worrying much about what kind of standards they are coming up with or even how rough. He is 
also trying to set an endpoint to the seemingly interminable working-group process, a date on 
which everything (whatever there is) would be handed over to a "scribe".^ 

As it turned out, these details did not matter. Only Miller seems to have taten even the 
first step the email called for. Qn March 3, two days behind schedule but on the day he received 
Gotbeibam's email, he wrote his working group a "hello message" (one indicating, in passing, 
that his working group had been entirely inactive until then): 

Thank you for your interest in ACM and IEEE effort to professionalize software 
engineering. 

Ages ago (we're talking YEARS, not months) you expressed some interesting working 
on the Software Engineering Ethics and Professional Practices (SEEPP) Task Force, 
specifically the Working Group on Rdiatality and Safety. 

You may have thought this working group would never get down to work. (I certainly 
had MY doubts.) But it looks lite we may have a plan now. 

Before I waste bandwidth telling you about our plans, are you still willing to work with 
us. I hope so. Please let me know. 

Qn March 8, Weil emailed back "I, Michael Davis, and Ilene Bumstein, all from IIT, are still 
very much aboard Please mate sure we three each get all the e-mail messages in the Working 
Group on Reliability and Safety. We will join in. I have already sent Gotterbam a message [in 
response to the long email of March 3 to Working Group Leaders]. Please convey your plans to 
us. Best Vivian." Miller's March 3 email even reached Mechler (who was not in Miller's 
working group); Jayaram (who was in that group too) had passed it on.'° 

That is the last message that IIT (or Mechler) received from Miller for several months. 
There is a niystery here. Gotterbam' s archive contains a March 13 email from Miller addressed 
to 'Dear Working Group Members". March 13 is two days ahead of Gotterbam' s schedule for 
this message. Among the designated recipients (beside other working group leaders) are the 
members of Miller's working group (including Jayaram and "Weil, Bumstein, and CSEP 
[Davis]"). The email should have gone to everyone on the address list if it was sent at all (as it 
seems to have been), yet no one at IIT received it We know of it only because a copy survives in 
Gotterbam' s files (in at least three versions)." Because this email was not (according to the 
header) distributed through Gotterbam' s list none of the usual troubles with that list can explain 
what happened to it. Could it be a draft that Miller sent Gotterbam for comment? 

Gotterbam' s files contain a similar document addressed to his own working group; it 
seems to have been sent out two weeks late (if it was sent at all).'^ It should, lite Millars, have 
gone out on March 15. Mechler, a member of Gotterbam' s working group, should have been a 
recipient Yet, on March 18, 1996, v\ten Mechler emailed his volunteers the "final outline", he 
began: "I have not heard from Don Gotterbam since his e-mail dated 12/15/95; if ariy of you 
have heard please let me know." Jayaram responded the same day that all he knew about "the 
elusive Don Gotterbam" was his visit to Jayaram' s neighborhood (Febmary 1-2). (This was the 
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email Mechler passed on to SEEPP/E to explain why SEEPP/E members should visit other 
members when nearby.) Jayaram must also have communicated with Miller after March 3 (since 
the March 3 email was not addressed to Miller and yet Jayaram reports): 

There is another group chaired by Keith Miller who has contacted me re: Reliability and 
Safety standards- related work within the Ethics framework. You will not be surprised to 
note that he also cc: our beloved Don! I moaned about Don's insular habits these days to 
Miller in a cynical way. He seems enthusiastic with this reliability and safety work! 

I suggest we all produce a single e-mail message to Cabrera about Don' refusal to 
communicate with us. 

I feel that the whole exercise— plethora of workgroups is fast becoming a big joke. 

On April 6 (using the ETSU list), Gotterbam emailed his volunteers the plan that he was 
supposed to have sent out on March 15. Mechler (and IIT) received it but Jayaram (and perhaps 
others) did not.^^ The next day Gotbedem emailed working group leadens (and Little and me)— 
using the SEI list 

Howdy, 

I hope you are all ergoying Spring! Cold and snow here. Please let me know how 
you are doing with you[r] work groups. I know the schedule we put together in February 
is demanding. I have already missed some of the deadlines. But it is inp^rtant to get 
started even if we are a little late at doing it I used to say, I will get to that v\ten things 
slow down . . but they never slow dowa At least life is not boring. 

Please let me know if there is anything I can do to help with your work with the 
groups. 

Best regards, 

Don 

GotieriDam does not seem to have received arry response to this email. 

On May 15, 1996, Mechler emailed SEH'PNE: 'This is the message I received [from 
GotteriDam] after e-mailing Felipe Cabrera the new head of the Steer Comm I will be sending 
our work soon Please let me kri)w if you get it" At the end of March, Mechler had decided to 
do as Jayaram suggested, write something to Cabrera about 'T)on's refusal to communicate with 
us". That message does not seem to have survived, nor does Cabrera' srespjnse, if there was one. 
But a few days later (April 8), Gotberiaam emailed Mechlen 

Ed 

I am alive and apologetically slow to respond Thank you for your work on the 
project Please send your results to the list It may serve to bring some other folks into 
actiorL I will later work your sub-groups contributions and v\totever else we get into a 
strawman for everyone' s consideratiorL 

Again, thanks for the help. 
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Apparently, not much had changed since 1995. The only group, beside Gotledem's own (and 
Mechler' s), to shDw any life in eariy 1996 was MUer' s. But that was in March. Miller does not 
seem to have communicated with his working group in April, May, or June (or to have reported 
ariything to Gottedem). Miller seems to have missed a number of deadlines. For exanple, lite 
all other group leaders, he was supposed to send a "[revised] draft of... group's [substantive] 
document to men±)ens of SEEPP task force" on June 15. He did not (or, at least, there is no 
evidence that did) .'^ 

6.3 The exceptional Miller 

Just because Gottedem sent SEEPP no emails from eariy April to eariy June, we must 
not suppose he was inactive. He was certainly continuing to work to mate software engineering 
a professiorL For exanqie, he was in St. Louis, June 21-22, 1996, for the National Software 
Council (NSC) Forum on the Licensing of Software Professionals. Lawrence Bernstein, a 
men±)er of several SEEPP worldng groups, a vice-president at AT&T, and also NSC president, 
summarized v\tot h^Dpened by email (August 26, 1996).'^ Gottedem was not the only one 
irwolved in the joint lEEE-CS/ACM project presert. There were at least three others (beside 
Bernstein himself): Zweben, by then ACM Prudent; Chitefsky (^Dparently representing lEEE- 
CS); and Shaw (^parently, lite Gottedem, there sinqiy as an individual). Norm Gibbs was also 
thae, identified as at Guilford College, North Carolina, but "recently [head] of the software 
education program of the SEI". Shaw argued against licensing (as she regularly did) because 
"software engineering is immature conq^ared with dvil or chemical engineering". For software 
engineering to mature, it would have to consolidate and validate its "body of knov\dedge". She 
"asted v\teher software engineering was closer to mathematics than engineering." She also 
"discussed standards" calling for "codification of our body of software engineering knowledge". 
Gotterbam responded that "such a body of knov\dedge existed". What was lacking was an 
"accepted ethics of software engineering." He warned that "if the software engineering 
community does not step [in and] certify and license its professionals, the professional 
engineering community will." That would not be good because "[today's] state licensing 
examinations have little relevance to software engineering." Bernstein ended his report with his 
own recommendation for registering software engineers (rather than licensing them) . Among the 
details of his recommendation is the requirement that registered software engineers "advocate 
and practice [a] code of software engineering ethics for safe systems". Except for Gotterbam' s, 
his is the only reference to "ethics" to ^Dpear in the report 

According to the (admittedly anitatious) schecMe announced in March, Gottedem was to 
receive revised (substantive) docuriients from the working groups on July 15. July 15 came and 
went without one document arriving. Even Gottedem' s own working group on professional 
conpetence did not report Then, on July 16, he received an email from Miller, with a report 
attached, two-and-half pages single-spaced, on 'Testing, Rdialility, and Trustworthiness: 
Informed Consent and the Conpjting Profession". Miller had done wtet. he was supposed to 
do— and he had done it almost on time. Pedi^:s he had even done it on time. There was some 
confusion. The email referred to a "grievous enor^' of "yesterday", misspelling the name of 
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Thomas Hilton, a member of the group, "whose work I found so helpful". Yet the document 
itself contains no references whatever— to Hilton or to anyone else. So, there seems to be no 
reason why the report (rather than the covering letter) should have had to be revised since 
"yesterday" (or why its title should be "Revision 2"). Gotterbam does not seem to have received 
Miller's email of the day before, nor does anyone in IIT's research group. Perhaps, the retracted 
email had never been sent (or, perhaps, it went where so much of 1996's email already had). 

Miller's document ("Revision 2, July 16, 1996, Ham") seems to be what Gotterbam 
would describe as a standard of practice. There are eight unnumbered sections, beginning with an 
Introduction of four paragraphs describing a problem of "computer professionals"— determining 
"how good is good enough"— and a proposal to solve the problem through a procedure of 
"informed consent". The next section, three sentences long, states the "Guiding Principle": 

A software developer should obtain informed consent from the client. A software user 
should have available information about the safety and reliability of software. The public 
should be able to obtain detailed information about the testing and reliability measures of 
any commercial software. 

The section after that ("Definitions") defines five key terms in the Guiding Principle ("software", 
"software developer", "client", "user", and "public") and sends the reader to the next (five- 
paragraph) section, "Informed Consent", for the definition of that term. The section defining 
informed consent is followed by "Implementation of Informed Consent" (a single six-line 
paragraph) and a (half-page long) section "Contents of an Informed Consent" (divided into three 
subsections: "I. Product Measurements", "II. Process Description", and "III. Assessment 
Implementation". The final two sections (each a paragraph long) are "Contract Ramifications" 
and "Informed Consent Documents as Public Archives". The last quarter page of the document 
(three short paragraphs) is a commentary entitled "Why I Think This Might Work". 

Miller's document is clear, compact, and (seemingly) practical. It shows that Gotterbam 
was justified in suggesting him as SEEPP's "scribe". The document is, however, probably not 
the work of a "working group". Miller speaks as "I", not "we"; and the very quality of the 
exposition suggests that he has not had to make the compromises that working with a committee 
generally requires. He mentions no votes or approval (though he sent a copy to every member of 
his group, as well as to Melford, Gotterbam, and himself). He seems to have solved the problem 
of getting his working group to work by doing the work himself (perhaps consulting with Hilton 
or just reading something he wrote). Miller's solution to the problem of getting the working 
groups to work, the only one achieved so far, is further evidence that division into working 
groups may have been a mistake (even apart from the assurance problem discussed in 4.8). 

Miller's report also suggests a problem with developing standards of practice within a 
project to make software engineering a profession. The document never speaks of "software 
engineers" but of "computer professionals" and "software developers". The definition of 
"software developer" is quite broad: "any professional involved in the production of computer 
software; this includes but is not limited to designers, coders, testers, managers, and 
salespeople." The definition of "software" is even broader. Software includes "computer 
programs, intemal documentation, design documents, test plans, user manuals, online help, and 
the like." "Professional", while not defined, seems to mean nothing more than someone hired to 
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do a certain job, "a role" having "responsibilities and privileges". Put all this together and even a 
technical writer editing a user manual may count as a "software developer" for the purposes of 
Miller's document. Though the very broadness of definition is part of what would make the 
document useful, the document is not as written, a contribution to the professionalization of 
software engineering. (Technical writers, for example, belong to a different profession— with its 
own code of ethics.) Indeed, Miller's document says nothing about software engineering as such. 
That, perhaps, is why we hear nothing more of Miller's achievement. 



6.4 Getting back into the loop 

Gotterbam does not seem to have received or sent any messages to SEEPP, to his own 
working group, or to Mechler's group during the rest of July, all of August, and (almost all) of 
September. This is odd because the schedule he sent out in March had the following deadlines: 

Aug 15: first draft of complete, coherent document to task force. 
Sept 1 : revisions from task force to scribe. 
Sept 15: Scribe submits revisions to working groups and task force 
ct 1 : suggestions back to scribe from working groups and task force. 
Oct 15: Latest revision from scribe to Don and Bob. 

Begin discussion of materials with joint committee. 

As September came to an end, Gotterbam (now on sabbatical leave at George Washington 
University) would have had reason to think that (once again) he would have very little to show 
the Steering Committee when it next met. Miller's document, whatever its merits, was not the 
document promised, "a code of ethics and professional practices". It was, at best, a modest 
element of a much larger code of professional practice. The other seven official working groups, 
including Gotterbam' s own, had reported nothing. Mechler's group had last reported to 
Gotterbam in April. What that group had shown him then (Version 0) was not a "coherent 
document" but a disordered list, neither a code of ethics nor a code of practice. Since then, 
Mechler seemed to have disappeared. The project seemed doomed. 

Then, on September 30, Gotterbam received Mechler's email announcing "the [attached] 
final product of the Ethics group". Since Cabrera received the same email (as did Mechler's 
working group), SEEPP was, in a way, now fifteen days ahead of schedule: "discussion of 
materials with joint committee" had (it seemed) begun. Cabrera soon sent the code to the rest of 
the Steering Committee. During the next week, there was that flurry of emails described in 5.6- 
5.7: Frailey's critique (October 4), Mechler's response (October 6), Shaw's critique (October 7), 
Mechler's response to Shaw (October 7), and some lesser exchanges between Mechler and 
Cabrera. Because Frailey had sent a copy of his critique to Gotterbam when he emailed it to the 
rest of the Steering Committee, Gotterbam had seen it on October 4, even before Mechler had. In 
a few days Gotterbam had gone from worrying that there would be no code of ethics to worrying 
about whether the code would be rejected— without ever passing through relief at having 
something to show. Frailey had seemed to be a strong supporter of SEEPP' s work. If he was as 
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unhappy with the code as he sounded, others on the Steering Committee must (it seemed) be 
unhappier. Something had to be done, and soon, or the code would be dead. 

Evidence of that wider unhappiness arrived on October 1, Shaw's critique, which Frailey 
had himself passed on to Gotterbam with the covering note: "Don, I think the steering committee 
would like to hear some response to my comments and Mary's from those who formulated the 
draft code of ethics."^^ Frailey was right Indeed, v\tot was needed was a careful respjnse lite 
the p^:er Gotterbam had helped with Anderson and Johnson prepare for the ACM Council v\ten 
the ACM code was in danger. That would tate time to prepare, especially if the response was to 
come from SEEPP (as it should). Right now, Gotterbam seemed to be in an odd position He was 
neither on the Steering Committee's mailing list for discussion of the code nor on SEEPP/E's. 
He was "out of the loop". He knew v\tot passed between those two groups if, but only if, some 
member— Frailey (for the Steering Committee) or Mechler (for SEEPP/E)— sent him a copy of 
the relevant document He seemed to have lost control of the process for v\Mch he (as chair of 
the Professional Conpetence working group) or he and Mdford (as SEEPP co-chairs) were 
responsible. 

The next morning (October 8), Gotterbam announced to his working group a listserv he 
had been preparing for sone time, PRFCMP-L-Request@UTKVMl.UTK.EDU.' ^ More tiian a 
single-sp^:ed page of instiuctions explained how to use it Three hours later, Gotterbam used the 
listserv to send Version 1 to his working group and begin a process of review that might at least 
corMnce the Steering Committee not to mate up its mind right away: 

Dear professional con^Ddence working group men±)er. 

Below is a draft of a code of ethics developed ty a sub group lead [sic] ty Ed 
Mechler of the professional conpetence working group. 

We are soliciting comments from you on the code. We are especially interested in 
distinguishing between those inq^eratives which are asprational and those v\Mch can be 
embodied in a code of practice. It would be helpful if your suggestions were 
acconparded ty suggested rewording rather than just sending a general suggestions [sic]. 
Please ^jply your special expertises to this. 

A copy of this draft has been seen ty the steering [committee] and it was suggested ty 
one of their members that they review it in NOVEMBER! !, so your brilliant and r^d 
responses are encouraged 

Thanks for your help and continued interest 

donGottedem 

This message, though evidentiy written in haste, is more con^icated than it may seem on 
first reading. Gotterbam' explicit reference to distinguishing between inperatives that are 
"asprational" and those that can be "embodied in a code of practice" suggests that te thought 
that the chief problem with Mechler' s code was that it had failed to distinguish between those 
provisions v\Mch, being merely asprational, belonged in a code of ethics and those v\Mch, being 
meant to be enforced, belonged in a code of practice. Frailey and Shaw both seemed to otgect to 
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"aspirational" provisions because they thought they were intended to be enforced. They both 
seemed to envision a code much like the current ACM code. Gotterbam too had expected 
SEEPP's work to end in something like that document. It was, after all, "state of the art" in code 
writing. The problem, then, was how to move Version 1 in that direction. Technically, SEEPP 
was the body that should do that. But working through SEEPP would have meant working with 
Melford, SEEPP's co-chair, and working with Melford would be slow. Melford was now taking 
a very long time to respond to messages, when he responded at all. Indeed, Gotterbam had not 
heard anything from Melford since they had met in London in February. Gotterbam certainly did 
not have the time to wait for Melford now. Gotterbam did not need Frailey to suggest that the 
Steering Committee might vote on the code in November. Such a vote would only be natural 
given that they had the code in hand and the other two task forces were still far from having 
anything like it to present. 

Gotterbam nonetheless seems to have done his best to make clear that he was only 
addressing his working group, even using the salutation "Dear professional competence working 
group member" rather than his usual "Volunteers". This satisfied the letter of the requirement 
that he address SEEPP only with his co-chair's consent, but escaped the consequences. His 
working group included most of the members of the other working groups, including all the 
chairs of SEEPP's working groups. He could reach almost everyone, certainly everyone who 
mattered, while officially addressing only his own working group. 

For the same reason, Gotterbam explicitly treated what Mechler liked to think of as a 
working group, as a "sub group". Gotterbam would have had to consult Melford to deal with 
someone else's working group, even a spontaneous and unauthorized one like Mechler's. But, as 
a "sub group", Mechler's group was Gotterbam's business alone. There was no need to involve 
Melford— and therefore no need to wait until Melford responded. 

6.5 Politicking 

After this email, Gotterbam wrote another, this one to Mechler personally. In it, 
Gotterbam offered to help with drafting a response to Frailey and Shaw. Mechler did not receive 
that response until the next moming. By then, he had already responded. An important 
opportunity to mollify the critics had been missed. Gotterbam nonetheless tried to explain to 
Mechler the politics of the Steering Committee, urged him to take a look at the two codes the 
Steering Committee would likely use as standards against which to test Mechler's, and otherwise 
tried to prepare him for the work ahead. 

Mechler did not get around to sending Gotterbam a copy of his comments until two days 
later (October 11). By then, Gotterbam had received both from Frailey. When Gotterbam read 
them, he had been appalled. They did not strike him as polite, cool, or carefully argued. They 
were not at all likely to soften the opposition. They also seemed explicitly to deny the distinction 
between an (aspirational, general) code of ethics and (mandatory, specific) code of practice that 
Gotterbam, like Frailey and Shaw, took for granted. For Mechler, a code of ethics was 
mandatory— and as specific as it could be. Did Mechler's working group think the same way? Or 
was Mechler (more or less) on his own? Gotterbam could not tell. Over the next few days, 
indeed, over the next few weeks, no one in the Professional Competence working group 
responded to his October 8 call for criticism. Did that mean that everyone in the working group 
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(including Mechler's "sub group") approved of the code? That no one cared one way or the 
other? Or merely that no one in the working group had time to read and comment on so long a 
document? Or that the message had vanished into the ether? 

Last Gotterbam decided to see whether he could prevent the Steering Committee taking 
up the code in November. He emailed Frailey that he had "just got your response to the code of 
ethics" and agreed "with many of the concerns expressed. The original plan was to distinguish 
codes of ethics from codes of conduct and codes of practice."^^ Gotbertem then explained that 
the code "was developed by a sub-group led by Ed Mechlei^', that he (Gotle±iam) was "surprised 
when it was distributed to the steering commitbee before going through the kinds of revision and 
distribution we [had] with the ACM code", and that he was therefore "concerned about your 
suggestion to ^Dprove by November". While "sending it directly to the top is one way to get 
things moving"), there are "sensitive issues that need to be worked out and some restmcturing of 
the code that needs to be done before it is ready" : 

For exanple, given the current amliguous state of copyright legislation, that item has to 
be filled out in the code. Are we ultimately to have three types of code— ethics, conduct, 
and practice or follow the ACM model of a code and put standards of conduct in the 
guidelines. For a code to be effective, there needs to be sanctions such as removal from 
men±)ership in a society. Which society is sponsoring this and wiU there be similar 
sanctions from each society. Before the ACM code was ^proved it was submitted to the 
men±)ershipintheCACM [Communications of the ACM] and responses were solicited. 

Having thus reminded Frailey (the ACM-appointed vice chair of the Steering Committee) that 
"that is not how we do things at the ACM", Gotterbam admitted, "I am belaboring my point- 
one month from draft to approval seems rather fast." He then added one other consideration: He 
could not be at the November meeting (because he will "be attending an international computer 
ethics conference").^" 

This email seems to have had its intended effect Within a few minutes of receiving it 
Frailey forwarded Gottertem's email to Cabrara (with a cc to Gotteatam and everyone else on 
the Steering Committee). The covering note: "as you can see from the attached, the proposed 
code of ethics we received had not gone through the ethics task force and thus can best be 
considered a draft I suggest the steering committee be ^Dprised of this and that we send it to 
Gotteatem with an indication that it is in much too immature a state to ^Dprove at this point "^ ' 
The immediate crisis had passed 

On October 18, Frailey emailed Gotteibam again He needed "a few things [ty October 
25]". One was a description of contacts with "external" organizations (apparentiy, meaning 
"foreign" rather than non- ACM organizations). Frailey helpfully provided a "model entry" using 
PASE'96 (Professional Awareness for Software Engineers, a conference held in 1996). Frailey 
needed this list because he was putting together "a chronology of all external organizations with 
whom the software engineering activity has interacted" for Chuck House, the new ACM 
president The other item Frailey needed was an "update on plans for 1996", noting that the plan 
GotieriDam had drawn up in January called for "a meeting in Washington in October or 
November to have the group do a final lun through of the document' and "[delivery of] the 
document to the steering committee."^ ^ 
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Gotterbam's response tells us at least as much about his state of mind at this time as 
about the state of SEEPP. After acknowledging that Frailey would not "be happy with the level 
of detail that follows", he explained why he could not then do better: 

I am now in Leesburg VA teaching at George Washington University [Ashbum 
campus] while on Sabbatical leave... .This is my first sabbatical and it is an 
organizational nightmare. Some of the names and email address[es] you requested are 
locked in a file cabinet in Tennessee but they are also in one box or another of materials I 
have been forwarding to England [where the second half of his sabbatical year would be]. 

Gotterbam's list of "external contacts" is short, consisting in large part of the panelists with 
whom he shared the stage at PASE'96 (beginning with the two, Tracy Hall and Colin Myers, 
whom Frailey had mentioned in his "model entry"). There are, however, four exceptions. One is 
Rogerson. Gotterbam will be at his Centre "developing standards of practice in project 
management and... revising and developing materials for the task force." The second contact is 
an unnamed representative of the (British) Institute of Electrical Engineers (lEE). Gotterbam was 
"looking for guidance on the development of standards and soliciting their participation in the 
development and the review process. The individual I spoke with declined the offer and 
indicated that such participation was not a high priority for lEE." The third contact is "Tony 
Cowling, one of the developers of the BCS [British Computer Society] undergraduate software 
engineering degree; the fourth, "Duncan [Langford], an author of an applied computer ethics 
text." These last two are described as among other "volunteers in England who have already 
been contributing to the documents developed."^^ Gotbertem does not say v\totthe "documents" 
in question are or how Cov\ding and Langford contributed (The two had, of course, nothing to do 
wrth the drafting of Version 1, though Langford would soon begin contributing.)^ * 

Gotterbam concludes this email with another note (marled by another salutation) : 

This does not fit easily into your tenplate. First week of Noven±)er I am going to a 
corrpiter ethics conference and will do some specific recruiting, in particular I want to 
irwolve people from the US based center for Conpjting and Social Values [the Research 
Center for Corrprting and Society at Southern Connecticut State University]. Later in 
November I am doing a videot^:e for the SET on ethical issues in project management 
and will tate the opportunity to meet with some of rry working group who are centered 
in Pittsburg [e.g., Mechler]. <- 1 know Pittsburgh is not a foreign country.^ ^ 

The information Gotterbam provided Frailey, however thin, cleariy assumes that SEEPFs work 
will not end in November. Gotterbam will be working on the code vMle in England, starting 
January 1997. But the information, v\totever its assun^Dtions, sounds strangely lite v\tot 
Gotterbam could have written a year or two earlier. He cannot report that his worldng group is 
actually working on the code. Or even that his working group (or ariy other) is working. The 
most te can report is that he will recruit people (for SEEPF s working groups)— as if he had not 
recruited enough people already. 

6.6 More comments on Version 1 
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Between the time Frailey asked for a report and the time Gotterbam answered, Gotterbam 
received two responses to his request for comment on Version 1. One, from Langford, an early 
SEEPP volunteer, began by declaring the code "impressive". The eight specific suggestions for 
improvement that followed the declaration show how impressive Langford actually thought the 
code. He had one overall suggestion: "I'm not sure that 'assure' is the right word; would 'ensure' 
be better?" The specific suggestions, though all minor, reveal a careful reading of the code. He 
proposed amending Rule 1.03 ("Asssure that they are qualified, by education and experience, for 
any project on which they work") by appending "or propose to work"; Rule 1.14 ("Avoid fads, 
departing from standard practices only when justified") by inserting "technically" before 
"justified"; Rule 2.01 ("Disclose to appropriate persons any danger...") by inserting "actual or 
potential" before "danger"; and so on, always adding to the precision of the rule or raising the 
standard it set.^^ 

The same day (October 22), Gotterbam also received a long email from Milton Ful^mm, 
Senior Staff Engineer at FlightSafely International (Missouri), another eariy SEEPP volunteer.^ ' 
Fulghum offered no overall evaluation of the code, but his page and a half of suggestions, as 
specific as Langford' s, cleariy tate the code's overall shuctuie for granted Most of his 
suggestions are organizational— and minor— for exanqie Clauses 1.05 and 1.14 should be 
comtaned since "1.14 seems to be a specific case of 1.05." Clause 2.03 "might better fit under 
another rule, perii^:s Rule 3". Clause 2.04 should be moved to Rule 1. But one of the 
organizational changes is major. He notes that marry of the clauses in Rule 6 (in particular 6.07, 
6.08, 6.09, and 6. 14) 

address management issues instead of peer-to-peer relationships as inqiied in 
'Colleagues' titie. The clauses [in 6] should focus on peer-to-peer issues. Perii^:s another 
rule should be drafted to address management issues. 

Fulghum ends by wondering how "does this [code] conpare with" the new ACM and IEEE 
codes.^^ 

On November 7, Mark KankD, M^or, US Air Force, used the listserv to ask v\teher 
"you are still accepting irpjts".^^ KankD had assigned the code to his "graduate students (some 
with real-worid experience, some not)." He would be h^Dpy to send the results. Gotterbam 
responded two days later (using the listserv): "I would love to see them Sony about the delay in 
responding, I was at Ethiconp 96 all week [Madrid] . I would also ^predate your comments."^ ° 

The next day (November 10), Gotterbam received another response to his call for 
comments (an email sent directiy to his "gwu" address). It came from one "Peter Ron Prinzivalli, 
IEEE member^', of San Jose, Califomia Prinzivalli was the Principal Software Consultant of his 
own conpany. He had been involved in "software devdoprnent, QA, maintenance, and 
production" since 1966, served as Treasurer of the lEEE-CS Standards Activity Board 1984r87, 
and been a member of Gotterbam' s working group (and three others) since November 17, 
1994.^' LiteKankD, he was an engineer rather than a conpjter scientist^ ^ And also like Kanko, 
he had never before responded to any of Gotterbam' s emails. But his response now, over two 
pages of "comments" and "edits", followed by some extremely kind words, made up for his two 
years of silence. 
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Prinzivalli's concerns seemed different from the other commentators', positive as well as 
negative. He began by asking what would happen next "after this working group is finished with 
it". Will it go to lEEE-CS "Governing Board and DC Staff"? What will be done about its 
"propagation and maintenance"? He then wonders to whom it will apply: "programmers with no 
formal education or programmers who are not software engineers by university/trade school 
degree?" What he really wants to know is whether "software engineer herein mean[s] EE- 
SWEng"? As an engineer, he is concerned that the term "engineer" be reserved for engineers 
who have graduated from an A BET -accredited program— or, at least, something very close, not 
for mere "programmers with no formal education". (He is therefore interested in how the code's 
"term"— "software engineer"— connects with the body of knowledge and curriculum the 
Steering Committee is also working on.) The specific changes he suggests are (mostly) quite 
minor and distinctly his own. For example, he suggests substituting "must" for "shall" in the 
Introduction ("Software engineers shall commit themselves..."); "authorities" for "persons" in 
2.01; and "required" for "appropriate" in 2.02. But some of his suggestions resemble those 
Frailey and Shaw made. For example, Prinzivalli prefers "documented" for "put in writing" in 
1.01 (to "cover all electronic documentation"); he does not think Rule 1 is "possible" (unless 
there is an "acknowledged 'professional' process of supervision"); and he is not sure what 6.11 
means ("Not supplant another software engineer after steps have been taken for employment"). 
Overall, Prinzivalli's suggestions seemed to move the code language away from the ethical and 
toward the legal, but his overall evaluation was much the same as Langford's and Fulgum's: 

Don, congratulations on getting the process this far. I have participated in several IEEE 
software development standards. Software Standards Conferences, as well as on the 
Society's Standards Activity Board. Consensus and participation is always difficult to 
shepherd into productive useful Standards and Codes. Good luck with the final stages of 
authorization and publication. 

I'd suggest that the Society provide sessions at all of our Conferences and Tutorials to 
propagate the Code. Each member and non-IEEE member should be able to attend these 
sessions, and the Society should maintain a Registry of all individuals who have 
form[al]ly agreed to follow the code. 

6.7 Kanko's student comments 

Gotterbam met with Mechler for lunch, November 18, a get- acquainted meeting without 
agenda or definite outcome. When Gotterbam got back to Leesburg, Kanko's "comments", all 
thirty-two single-spaced pages of them, were waiting. Kanko had asked his class of fifteen 
students to read Version 1 and a) comment on the code generally, b) identify "no more than three 
individual imperatives that should not be part of the code, and c) identify "no more than six of 
the individual imperatives that are aspirational". Kanko's students were all officers enrolled in a 
course in the Department of Electrical and Computer Engineering, Graduate School of 
Engineering, Air Force Institute of Technology. They were therefore likely all to have trained as 
engineers and to have had most of their practical experience, if any, inside the Air Force. Their 
responses were unlikely to provide a good indication of how software engineers generally would 
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respond. Worse, Kanko's assignment itself also seemed unlikely to provide a representative 
evaluation of the code. The assignment included some clear biases, for example, that there must 
be at least three imperatives that should not be part of the code. At best, Kanko had provided one 
data set among the many that would be needed to evaluate the code— but, on that November day 
in 1996, Kanko's was by far the largest data set Gotterbam had. Gotterbam read on. 

The responses, each about two-pages long, did not sound particularly "military". Though 
some of the students explicitly identified themselves as young officers ("lieutenants"), they do 
not seem much more obedient to orders than their civilian counterparts. One student flatly 
refused to identify any imperative to be removed: "I feel all the imperatives have a place in the 
code." Another identified only two imperatives for removal. Another, after listing three 
imperatives for removal, suggested adding one ("1.15 Assure the quality of the product meets the 
quality requirements of the user and/or employer"). And one went far over the quota (naming 
five imperatives for removal plus "most of 3.0x"). Kanko's students responded with equal 
unpredictability to part c of his assignment (six aspirations). 

Overall the students' evaluation of Version 1 was mostly either favorable (7) or "mixed" 
(6), with only one student clearly negative and one that simply did not state a position. The 
overall pattern of recommended deletions is interesting. None of the imperatives suggested for 
removal are in Rule 2 or Rule 7. The most targeted (with 6) is 1.14 ("Avoid fads, departing from 
standard practices only when justified"); the next (with 5) is 5.07 ("Only accept a salary 
appropriate to professional qualifications"). There were two imperatives three students would 
delete: 4.01 ("Provide service only in areas of competence") and 5.11 ("Serve in civic affairs 
constructively"). Five imperatives were named twice (1.13, 4.02, 5.03, 5.10, and 6.11). Thirteen 
others were named only once (among them some, but only some, that Frailey or Shaw 
complained about). Ignoring the answer "most of 3.0x" (that is, one student's vague suggestion 
to remove most of the provisions under "Judgment"), most of the code (49 out of 71 imperatives) 
seemed to have passed muster— or, at least, to have passed without comment. 

The students' attempt to identify "aspirational" provisions suggests some trouble with the 
term or the concept. Some students explicitly defined "aspirational": a provision was an 
aspiration if it stated a standard the satisfaction of which is "hard to measure" (because it is open 
to interpretation, is not a "yes/no", or not easy for others to check performance on). For others, 
the aspirational imperatives seem to be those that, though "laudable", are "unrealistic" or at least 
hard to satisfy. One student identified the Rules as aspirational (even though he also thought 
there was one too many). One said that the entire code was aspirational; one singled out 
"everything in 7"; and one just did not answer. Not one of the students equated "aspirational" 
with "general" (as Gotterbam had in his March 3 email). 

Most of the specific imperatives identified as aspirational were either under Rule 1 
Product (30) or Rule 5 Profession (22). The imperatives under Rule 6 Colleagues came in a 
distant third with only five mentions. The imperative most often identified as aspirational was 
5.01 ("Associate only with reputable businesses") with six mentions. Runners up were 
imperative 5.04 ("Help develop an organizational environment favorable to acting ethically") 
and 1.04 ("Assure proper goals and objectives on any project on which they work") both with 
five. Two more, 1.02 ("Assure that they understand fully the specifications for software on 
which they work") and 3.01 ("Maintain professional skepticism with respect to any software or 
related documents they are asked to evaluate"), received four mentions. Four others received 
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three (1.05, 1.06, 5.03, and 5.11); seven, two mentions; and the remainder one or none (ignoring 
the answer "all the rest"). 

Kanko's data suggest at least four comments. First, his students were not inclined to 
delete imperatives they regarded as aspirational. So, for example, the imperative most often 
picked for deletion (1.14) received only two votes for "aspirational", and the highest ranking 
imperative for aspiration (5.01) received no votes for deletion. Kanko's students seem not to 
object to a code of ethics containing aspirations. 

Second, while we might explain the high number of mentions of imperatives under Rule 
1 by location (first come, first picked), we cannot explain the status of imperatives under Rule 5 
that way. Something else made the imperatives under Rule 5 salient— both for deletion and as 
aspirations. We can only guess what. The students do explain why they chose the imperatives 
they chose but not why they did not choose the imperatives they did not choose. 

Third, the students seem not to have found the distinction between "standards of practice" 
and "aspirations" a natural way to divide up the code's imperatives. They also seemed not to 
share an unequivocal understanding of what the distinction is. 

Fourth, the students seem not to have paid much attention to the clause introducing the 
imperatives. Their evidence that a particular imperative is aspiration almost always comes from 
the language of the imperative itself. So, for example, though the imperatives under Rule 1 are 
introduced with what might be taken as aspirational language ("In particular, software engineers 
shall, as appropriate:"), no student quoted that language as evidence for the imperative being 
aspirational (not specific, requiring interpretation, or the like). In this respect, and only in this, 
Kanko's students seem much like Frailey and Shaw. They too seemed to read the code one 
"bullet" at a time rather than as an integrated document. The students did not even try to read the 
particular clause in light of the general rule it came under. Apparently, Version 1 is not as easy to 
use as Mechler (and, apparently, the rest of SEEPP/E) thought.^^ 

6.8 Conpjter scientists v. engineens? 

Gotlie±)am now had a riddle to solve. Mechler seemed to have a point v\ten he had 
responded to Frailey and Shaw by talking ahDut engineering codes of ethics. All the engineers 
responding to the code at all (and even most of the engineering students) lited the code. 
Whatever the merits of the individual criticisms Frailey and Shaw made, there seemed to be 
little, if ariy, overi^ between them and the "engineering response". For engineers, the code had 
no obvious flaw. Gotierbam could see v\^ corrprter scientists lite Frailey and Shaw would 
respond differently. The codes they were used to didn' t look much lite Version 1 . But it was not 
possible to explain their response sinqiy by the contrast between engineers and conpjter 
scientists. Langford, a Research Fellow in the Conpjter Laboratory of the University of Kent at 
CanteriDury, held a PhD. in Conprter Science (University of Kent, 1991)— with an 
undergraduate degree in social work^* In no sense an engineer, he too lited the code. Could the 
Frailey- Shaw response constitute nothing more than a statistical anomaly? 

The Steering Committee (minus all but one ex officio) met in Pittsburgh on Thursday, 
November 21. The "action items" (November 25, 1996) suggest that the Committee had been 
thinking about some of the things Mechler had said in defense of Version 1, especially his 
references to the "PE code of ethics". The first action item (for Cabrera "due 11/24/96") was to 
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send "Stuart Feldman [a computer scientists at IBM] a copy of the "code of Ethics of 
Professional Engineers and Civil [Engineers]". Melford (in town for another reason) undertook 
to rewrite (by "1/20/97") "the proposal for a Code of Ethics and Professional Practices for 
Software Engineers following the canonical form of those for Professional and Civil Engineers." 
He was to "produce a document that complements and expands those previously mentioned [to] 
align this proposal with that of sister disciplines [and be] different only when there is need to be 
different." Chikofsky (by "1/1/97") was to [identify] and secure relevant statements that address 
the issue of licensing software engineers [and send] the material to Felipe and e-mail to the 
whole steering committee regarding the findings." Melford also had two large assignments 
concerned with licensing. By "11/24/96", Melford was to provide Cabrera with "an initial 
statement of the question whether software engineers should be licensed engineers, to be used as 
the basis to present the forthcoming discussion on this subject."^^ By "2/20/97", Mdfoid was 
also to report "on the Conpjter Engineer exanqie [including] in the report their top-level 
definition of the field" (Mixed in with these items were similar items, but far fewer, concerned 
with the body of knowledge. For exanple, Frailey and Shaw were (ty "12/13/96") to produce "a 
set of paragraphs that describe the field of real-time software engineering" . 

Though addressed to "Ed", this email was intended for Melford (as Cabrera explained in 
a later email sent the same day). It is worth quoting in full: 

Marry thanks for your participation in our meeting last Thursday. I ^Dpredate 
your irwolvement and your work 

I did regret to be unable to talk longer with you about the stressing life situations 
that you have been going through. I look forward to spending some time at the next 
meeting in Febmary . 

FYI I enclose the conqiete list of action items that you helped us draft There are 
several that belong to you and [I] will ^Dpredate it very much if you let me know if 
clouds ^Dpear in the horizon and the work cannot be done. 

Melford must have read this email soon after his return to California looked at the demands his 
consulting business had been putting on him for well over a year ("stressing life situations"), and 
realized that (given that business was unliMy to slow down ariy time soon) he could not do v\tot 
he had promised Within a few days, he informed Cabrera of all "the clouds. . . in the horizon" and 
resigned as SEEPFs co-chair On Decen±)er 10, 1996, Gotterbam learned that he was now the 
solechair.^^ 

Frailey seems to have been the one to inform Gotterbam of his new authority. This he did 
ty phone on Decen±)er 12." Frailey also asked Gotterbam to prepare the three documents that 
Melford had undertaten to provide. Gotterbam did not accept the assignment as Frailey 
originally presented it Other i±Dne calls followed It was only on December 15 that they agreed 
on v\tot Gotterbam was to do. There would be three documents: 1) a statement descrihang the 
roles, stmctures, and functions of codes of professional ethics; 2) a detailed conqmson of 
Version 1 to other relevant professional codes (including but not limited to engineering's); and 
3) a revised code. Gotterbam would have nothing to do with licensing— even though he had long 
been an advocate of licensing. The code was in enough trouble without connecting it with the 
extremely contentious question of licensing. 
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6.9 Sole chair 

On December 18, 1996, Gotterbam began to exercise his new powers. He sent an email 
("Dear Task force members") using both a formal list "seep workgroup" and individual 
addresses for himself and most of the original members of SEEPP (Little, MacFarland, Miller, 
Sullivan, Barber, and Weisband— with Melford omitted, of course). The email also listed 
Mechler and his seven as individual addressees, with Cabrera and Frailey each receiving a cc. 
(Noticeably absent is Gotterbam' s own Professional Competence working group.) Though 
Gotterbam alone signed the email, there is no other indication of Melford's departure. 
(Gotterbam believes he notified the task force leaders of it two days before this email, in an 
email that has not survived.)^^ 

The list of addressees is nonetheless a hat odd Laurie Werfh, one of the original eight 
SEEPP members is missing. One of those on the list, Weisband, had not attended a SEEPP 
meeting, or even responded to an email, in well over a year. Little, McFariand, and Sullivan had 
also long since ceased to attend SEEPP meetings. Apart from Gotteitem and Mdfoid, SEEPP 
had become only Steve BariDer and Keith Miller. Having heard nothing from Barber in months, 
Gotterbam had emailed him, asking v\tether he received Version 1 ('T am really looking forward 
to you[r] perspective on it'). Gotterbam also asted for a report "telling me the stahjs of your 
group... arid v\tere you are in devdopng a preliminary statement" Bari^er wrote back on 
October 21: "We stould probably talk. My life is getting busier, and SEEPP is having a hard 
time finding it to the top of the list My strategy of procrastination is not serving any of us 
particulariy well." Having left law for software a year before, he found giving time to SEEPP 
increasingly haid^ ^ So, by November, he too had become one of SEEPF s phantom members. 

Gotterbam' s December 18 email begins on a high note ('It is time to move the code to 
the next step") but soon gets down to business ('It is evident from the comments [presumably, 
those of Frailey and Shaw] that we need to do some foundation building"). He then describes in 
detail the three docurnents he had prornised to deliver by February 1997 and sets out another one 
of his schedules ("The plan"): 

By the first week in January 

Send references to sources for inperatives in draft code to Don 

(Don) write draft statement about professional codes 
By Midjanuary 

Comment on draft about codes 

(Don) distribute statement about relationship of SE code to other codes 
By beginning of Febmary 

Achieve consensus on stmcture of code and start to revise it in the li^ of that 

consensus. 
By Mid February 

Revised draft of code ready for comment by Steering Committee. 
By the middle of March 

Have a discussion draft ready for distribution on the net and in professional 

journals 
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Have survey form ready for distribution with the code. 

Gotterbam concludes the email: "I know this [is] a lot to ask during this time of the year, but we 
have at last achieved something positive with the draft code and if we lose this momentum I am 
concerned that we will lose all credibility. But even more importantly, if we don't get the job 
done the concept of professional ethical standards will also lose credibility. I look forward to 
getting your responses... [etc.]" 

Mechler responded the next day (December 19, 1996), giving Gotterbam his new email 
address (again), and providing seven sources for the "Code we developed". The first on the list 
was the "IEEE and IEEE CS Code of Ethics"; the next (identified as the source of the "initial 
outline") was the National Society of Professional Engineers Code of Ethics (presumably, for 
version 0). The ACM code was listed fourth, just before the American Institute of Certified 
Public Accounts Professional Standards Manual. Listed last (after the "PA State Registration 
Board of Professional Engineers, Land Surveyors and Geologists The Code of Ethics and the 
Law" was a publication of the American Society of Mechanical Engineers, The Unwritten Laws 
of Engineering by W. J. King. The next email Mechler received from Gotterbam was a two-page 
form letter (January 1, 1997): "You have been added to the PRFCMP-L List".^° The only 
evidence that Gotterbam ever received Mechler' s December 19 email, if he did, is that 
Gotterbam later used the references in the memo on sources of (7.3). But, by then, Mechler had 
resent the list Qanuary 30, 1997). Mechler' s December 19 email seems to be another of the lost 
emails of 1996. 

No one but Mechler seems to have respjnded to Gotterbam' s December 18 email. So, as 
Gotterbam prepared for the second semester of his sabbatical, the prospects for SEEPP would 
have looted neither as bright as two years ago nor as dark as one year ago. Qn the dark side, 
SEEPP no longer seemed a large organization— or, at least, one that responded enthusiaslically 
to Gottedem' s call to actron Qn v\tom could he count? Mechler, Miller. . . v\to else? Gottedem 
would be spending the remainder of his sabbatical, the first half of 1997, in England— at 
Rogerson's center. Staying in England meant he could attend few of the meetings he usually 
attended, could not count on marry of the face-to-face meetings that seemed to have tept SEEPP 
going so far, and so might have the least help v\ten he needed help the most. What could 
England offer instead? Qn the bright side, Gottedem at last had a draft of the code of ethics, a 
much sinplified decision process, and a relatively undemanding schedule during v\Mch to work 
on the code. He could organize SEEPP as he thought best, without having to wait for Mdf ord' s 
approval. He was now in charge. 
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6. APPENDIX: CODE OF ETHICS FOR SOFTWARE ENGINEERS vl.0 September 1996 

INTRODUCTION 

Computers now have a central and growing role in commerce, 
industry, government, medicine, entertainment, and ordinary life. 
Because the utility of computers depends in large part on the 
instructions written for them, those who design, develop, and 
test software have enormous opportunities both to do good and to 
cause harm. To assure, as much as possible, that this power will 
be used for good, software engineers commit themselves to making 
the design, development, and testing of software a distinct, 
beneficial, and respected profession. In accordance with that 
commitment, software engineers shall adhere to the following 
standards of conduct. The seven main paragraphs state general 
rules. Each subsidiary clause is a specific application of its 
general rule, one experience has shown needs express statement; 
but no set of subsidiary clauses exhausts the general rule. 

Rule 1: PRODUCT. Software engineers shall, insofar as possible, 
assure that the software on which they work is useful to public, 
employer, customer, and user, completed on time and at reasonable 
cost, and free of significant error. In particular, software 
engineers shall, as appropriate: 

1.01. Assure that specifications for software on 

which they work have been put in writing, 
satisfy the user's requirements, and have the 
customer's approval. 

1.02. Assure that they understand fully the 

specifications for software on which they work. 

1.03. Assure that they are qualified, by education and 

experience, for any project on which they work. 

1.04. Assure proper goals and objectives for any 

project on which they work. 

1.05. Assure proper development methodology on any 

project on which they work. 

1.06. Assure proper management on any project on 

which they work, including proper procedures 
for control of quality and risk. 

1.07. Assure proper estimates of cost, schedule, 

personnel, and outcome on any project on 
which they work. 

1.08. Assure adequate documentation on any project 

on which they work, including a log of 
problems discovered and solutions adopted. 

1.09. Assure proper testing, debugging, and review 

of software and related documents on which 
they work. 

1.10. Assure that software and related documents 

on which they work respect the privacy of 
those who will be subject to the software. 
1.11 Assure that raw information used in software 

is accurate, derives from a legitimate source. 
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and is used only in ways properly authorized. 

1.12. Assure ethical, economic, cultural, legal, 

and environmental issues are properly 
identified, defined, and addressed. 

1.13. Promote maximum productivity and minimum 

cost to employer, customer, user, and public. 

1.14. Avoid fads, departing from standard 

practices only when justified. 

Rule 2: PUBLIC. Software engineers shall, in their professional 
role, act only in ways consistent with the public safety, health 
and welfare. In particular, software engineers shall: 

2.01. Disclose to appropriate persons any danger 

that the software or related documents on 
which they work may pose to the user, a third 
party, or the environment. 

2.02. Approve software only if they have a well-documented 

belief that it is safe, meets specifications, and 
has passed all appropriate tests. 

2.03. Affix their signature only to documents 

prepared under their supervision and within 
their areas of competence. 

2.04. Cooperate in efforts to correct problems in 

software or related documents. 

2.05. Be fair and truthful in all public statements 

concerning software or related documents. 

2.06. Not put self-interest, the interest of an 

employer, or the interest of a client or 
customer ahead of the public's interest. 

2.07. Accept full responsibility for their own work. 

Rule 3: JUDGMENT. Software engineers shall, insofar as possible, 
protect both the independence of their professional judgment and 
their reputation for such judgment. In particular, software 
engineers shall, as appropriate: 

3.01. Maintain professional skepticism with 

respect to any software or related documents 
they are asked to evaluate. 

3.02. Reject bribery. 

3.03. Accept no payback, kickback, or other 

payment from a third party to a contract, except with 
the knowledge and consent of all parties to the contract, 

3.04. Accept payment from only one party for any 

particular project, or for services related to the 
same project, except when the circumstances have been 
fully disclosed to the parties concerned and they have 
given their informed consent. 

3.05. Neither solicit nor accept a contract from a 

governmental body on which a principal or 
officer of their employer serves as a member. 

3.06. Participate in no decision of a governmental 

or professional body, as a member or advisor, concerned 
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with software, or related documents, in which they, 
their employer, or their client have a financial interest, 
3.07. Disclose to all concerned parties those conflicts of 

interest that cannot reasonably be avoided or escaped. 

Rule 4: CLIENT AND EMPLOYER. Software engineers shall, consistent 
with the public health, safety, and welfare, always act in professional 
matters as faithful agents and trustees of their client or employer. 
In particular, software engineers shall: 

4.01. Provide service only in areas of competence. 

4.02. Assure that any document upon which they 

rely has been approved by someone qualified 
to approve it. 

4.03. Use the property of a client or employer 

only in ways properly authorized. 

4.04. Not knowingly use pirated software on 

equipment of a client or employer or in work 
performed for a client or employer. 

4.05. Keep as confidential information gained in 

their professional work that is not properly 
in the public domain. 

4.06. Identify, document, properly report to employer 

or client any problem in the software or related 
documents on which they work. 

4.07. Inform client or employer promptly if, in 

their opinion, a project is likely to fail, 
to prove too expensive, to violate copyright 
laws, or otherwise to turn out badly. 

4.08. Accept no outside work detrimental to the 

work they perform for their primary employer. 

4.09. Represent no interest adverse to their 

employer's without the employer's consent. 

Rule 5: PROFESSION. Software engineers shall, in all professional 
matters, advance both the integrity and reputation of their 
profession. In particular, software engineers shall, insofar as 
possible: 

5.01. Associate only with reputable businesses. 

5.02. Assure that clients, employers, and 

supervisors know of this code of ethics. 

5.03. Support software engineers who do as this 

code requires. 

5.04. Help develop an organizational environment 

favorable to acting ethically. 

5.05. Report violations of this code to 

appropriate authorities. 

5.06. Take responsibility for detecting, 

correcting, and reporting errors in software 
and associated documents on which they work. 

5.07. Only accept a salary appropriate to 

professional qualifications. 
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5.08. Be accurate in stating the characteristics 

of software on which they work, avoiding not 
only false claims but claims that might 
reasonably be supposed to be deceptive, 
misleading, or doubtful. 

5.09. Not promote their own interest at the 

expense of the profession. 

5.10. Obey all laws governing their work, insofar 

as such obedience is consistent with the 
public health, safety, and welfare. 

5.11. Serve in civic affairs constructively. 

5.12. Improve public knowledge of software engineering. 

5.13. Share useful software- related knowledge, 

inventions, or discoveries with the 
profession by reading papers at professional 
meetings, by publishing articles in the 
technical press, and by serving on the 
profession's standard-setting bodies. 

5.14. Make no political contribution, gift, or 

commission for award of a contract. 

Rule 6: COLLEAGUES. Software engineers shall treat all those 
with whom they work fairly. In particular, software engineers 
shall, as appropriate: 

6.01. Assist co-workers in professional development. 

6.02. Review the work of other professionals only 

with their knowledge. 

6.03. Credit fully the work of others. 

6.04. Criticize the work of others in an objective, 

candid, and properly-documented way. 

6.05. Give a fair hearing to the opinion, concern, 

or complaint of a colleague. 

6.06. Assure that employees are informed of 

standards before being held to them. 

6.07. Assure co-workers know the employer's policies 

and procedures for protecting passwords, files, 
and other confidential information. 

6.08. Assign work only upon considerations of 

professional qualifications. 

6.09. Provide for due process in hearing charges of 

violation of an employer's policy or of this code. 

6.10. Develop a fair agreement concerning 

ownership of any invention an employee makes. 

6.11. Not supplant another software engineer after 

steps have been taken for employment. 

6.12. Attract employees only by full and accurate 

description of the conditions of employment. 

6.13. Offer only fair and just compensation. 

6.14. Not prevent a subordinate from taking a better job 

for which the subordinate is qualified. 

Rule 7: SELF. Software engineers shall, throughout their career, 
try to enhance their own ability to practice their profession as 



149 



it should be practiced. In particular, software engineers shall 
continually endeavor to: 

7.01. Improve their knowledge of recent 

developments in the design, development, and 
testing of software and related documents. 

7.02. Improve their ability to create safe, 

reliable, and useful software at reasonable 
cost and within a reasonable time. 

7.03. Improve their ability to write accurate, 

informative, and literate documents in 
support of software on which they work. 

7.04. Improve their understanding of the software and 

related documents on which they work and of the 
environment in which they will be used. 

7.05. Improve their knowledge of the law governing the 

software and related documents on which they work. 

7.06. Improve their knowledge of this code, its 

interpretation, and its application to their work. 
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NOTES 

^ Interview of Ba±er, November 14, 2002, answer to question 8. 

^ The difficulties in the way of iBConstmcting v\tot had h^Dpened in March 1995 were 

considerable; their description reveals as much about the irrpDrtance Gotterbam still assigned the 
Guide as about Barben 

Ldt me know if you need help interpr^ng the diff output, but hey— man diff. The diff 
output shows more changed text than there actually is because I re-justified the 
paragi^±is I changed I've annotated the diff output to indicate the Guide paragi^±i in 
which the change belongs. 

These changes have been reconstructed using rny notes made at the time. The rxjtes were 
notconplete, ard in hmt^ cases were but a few words intended to convey the idea or the 
change. I've written new language using the notes as a basis, but do not pretend that rr^^ 
language here replicates the language we came up with together at that rneeting. 

There were two instances v\tere I merely noted the word "change" with an arrow 
pointing to the affected text I have not atterr^Dbed a reconstmction in these instances, but 
have merely highlighted the area Perh^:s the identification will jog someone' s memory; 
I have no independent recollection of those changes. 

Gotterbam\Seep01d 94r96\diaft of guide Jan 96.GDE Qanuary 27, 1996). 

^ Interview of Rogerson, Febmary 24, 2003, answers to questions 1-3. Rogerson statement 

that he is not an engineer is odder in Ehgland than inthe US (and therefore suggests that he has 
given the question considerable thought). The British Conpjter Society is a member of the 
(British) Engineering Council. Any graduate of an accredited conpjter science program is as 
eligible to become a Chartered Engineer as the graduate of a mechanical, civil, or electrical 
engineering program See Trevor Bunidge, "Certification in the United Kingdom", IEEE 
Software November/December 1999: 46. 

^ Interview of Rogerson, Febmary 24, 2003, answer to questions 5-6. 

^ Gotterbam, General Comments on Ch^Dters 2 and 3, June 6, 2003. 

^ Gotberbam\SEEPP1996-97\SEEPBIL\Meetl ('T)ear Messrs. Cabrera and Frailey"). 

' Gotterbam\SEEPP1996-97\SEEPBIL\Meetl. 

" While three-part distinctions between kinds of codes are common, this particular one 

(between ethics, coriluct, and practice) is not Conq^re Mark S. Frantel, "Professional Codes: 
Why, How, and with What Inpact?", Journal of Business Ethics 8 (Febmary- March 1989): 109- 
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115; or the various articles in Margaret Coady and Sidney Block, editors, Codes of Ethics in the 
Professions (Melbourne University Press: Carlton South, Victoria, 1991), important works 
Gotterbam might have drawn on. 

^ Qf course, this "scribe" is a standard feature of IEEE standards devdopment SEEPFs 

Guide 4.1.4 specifically provides: "The WG Chairpenson should then identify an individual to 
author an initial draft. The author should be permitted to prepare the draft with or without 
additional irpjt or assistance from ariy other WG men±)ers, at his or her discretiorL" Gottertem 
Archive, 94r96 MSC, OPGUIDE feb 96. The only novelty is having a task- force scribe, another 
indication that the working groups were not working as they would in any ordinary IEEE 
standard- writing project. 

' ° Mechler' s archive E960318B. 

'' Gotterbam\SEEP1994-96\Miller to R&S WG; and Gotterbam\SEEP\1996-97\Miller 
(with the time stamp and other formatting of an emailed actually sent); and 
Gotterbam\SEEP1996-97\COMPET from GD and KM. 

' ^ Gotterbarri\SEEP1994r96\MCOMPACS (in four different forms, but all with files dated 
April 6, 1996). 

' ^ Mechler (March 20, 1996): 'It is funriy that you did not get Dons e-mail, I thought it was 
caused by a[n] e-mail from you and you were on the original mailing list." Jayaram was on the 
original mailing list, but his address, lite almost everyone else's, had changed a tat since. 
Gotterbam could only update the list if informed of a new address. 

' * irr Archive, April 8, 1996. 

' ^ Qf course, missing such deadlines may, or may not, mean a group is working. By June 
15, Mechler was in the last stages of polishing Version 1. Though he had sent a copy of most 
drafts of Version 1 to Cabrera v\ten distributing them to SEEPP/E, he had not communicated 
with Gottertem for several months. The same may, as we shall see, have been tme of Miller. 

'^ Bernstein seems to have used a mailing list having nothing to do with SEEPP. At IIT, 
only Bumstein received Bernstein' s message. 
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GotterismWersion (AAC0DE4. 



'^ There were a number of reasons for this new listserv, including the advance of 
technology. But one of them was that Gotterbam, on leave, was no longer in a position to teep 
the close vvatch on v\tot canie in and should go out as he had been v\ten back at East Tennessee. 
As he later recalled (email, Fefcruary 17, 2004): "I went on leave— Summer & Fall 1996 1 was at 
George Washington University— it took two months before they had me on E-mail so I was 
using a commercial E-mail address for a v\Mle— need to notify the Urdv of Tennessee [in order 
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to do anything with listserv]." Gotterbam does not recall when he received his official GWU 
email address. The earliest email from Gotterba(5) seasva.gwu.edu seems to be September 9, 1996 
(to Mechler). E9696. 

^^ TMs, of course, is Gotbeibam's iBconstmction of events. In fact, the original plan does 
not seem to have distinguished between codes of ethics, conduct, and practice— until 
Gotie±)am' s meeting with BariDacci and Mdfoid in January 29, 1994 (3.4). 

^° GotteibamWension 1\AC0DE1. 

^' GotteibamWension 1\AC0DE1. 

^^ Gotterbam\SEEP1996-97\RENEPTW. 

^ ^ Gotte±iam\Steering CommittteeVdf-n^TiarL 

^ * Cov\ding is neither on any of Gottedem' s eariy address lists nor on the final list of code 
"authors". There is nothing in the archives to suggest he ever contributed anything. The first of 
Langf ord' s contribution seems to have arrived a day or two before Gotterbam reported him as a 
contributor (as explained below). 
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Gotterbam\Steering CommittteeVdf-n^TiarL 

Gotteri:am\Vensionl\CMTDUNCAN. 

Gotterbam\1994r96 MISC\SEEPVOLS-list 2-95, pp. 26-27 (Fulghum). 

GotteriBm\Vensionl\CMTFULG. 



TMs is the KankD ("the M^or") v\to had a year earlier told Mechler (Ch. 4.6) that he was 
not in the Professional Conpetence working group but in Sullivan's on Privacy. Apparentiy, 
neither KankD nor Mechler ever informed Gotterbam of his preference for another working 
group. Now, the failure to cleanse the mailing list of the silent paid off. The moral here seems to 

be: you never know what people will do if you give them the opportunity to do something both 
useful and within the bounds of what they want to do. 

^ ° "ETHICOMF' is the acroriym for the 'International Conference on the Social and Ethical 
In^BCts of Information and Communication Technologies", a conference held annually in a 
European dty. The first, organized by Rogenson and Teny Bynum (Southern Connecticut 
University) was held in 1995 at DeMontfort 

^' Gotteri»m\1994r96 MISC\SEEPVOLS-list 2-95, pp. 56-58 (Prinzivalli). 

^^ Gotterbam\SEEP 1994-96\VOLAFIT 2-23-95. 
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^^ I too vvas(isappoiritEd Tte lesson I took from the response tD KankD's assignment is that 
codes are not self-interpreting; those who are to use a code should be taught how to interpret it 
Gotterbam way have taten a similar lesson from the comments, adding to his reasons for 
wanting the Preamble to provide a detailed guide to interpreting the Code. 

^^ Gotterbam\1994r96 MISC\SEEPVOLS-list 2-95, pp. 42-43 (Langford); Email (Langford 
to Davis), March 15, 2004. 

^ ^ Apparently, licensing was a sutgect that the Steering Committee could not separate from 
its thinking about professionalization— even though the subject had officially disappeared (two 
years before) betwrni the Board of Governor's ^Dproval of the "blue ribbon committee" (2.4) 
and that committee' s first report (2.5). 

^^ Gotterbam thinks my treatment of Mdford here— and in the preceding chapters— too 
lenient (Gotterbam\2003 SEEPRThree more Ch^Dters 5-7, Septen±er 1, 2003): 

I guess v\tot irritates is that your description of his "resignation" seems to indicate that he 
was working hard all along and that it just became too much work for him Even when 
his conpary was floundering- he had the same ^Arork pattern Rfimen±)er this had been 
smoldering since February of 1996 at the ACM meeting. Did he ever even organize his 
own working group? etc. Two documents of boiler plate at the front end of the project 
No need to dig deeper, just please change the tone of the poor down trodden over worted 
Mdford description - Without further corroboration you can see that Mdford set himsdf 
a bunch of tasls on the spur of the moment at that meeting, but fortunatdy this time he 
realized that he was- (MD pck one) totally out of the loop as far as the code was 
concerned and as far as ary work with the other working groups was concerned, 
urpepared to do what he said he would do, realized his own work pattern rdated to this 
project- set drearry goals without intention to do v\tot needed to be done to ddiver, said 
things as usual just to irrpess the IEEE power broters, and THIS TIME did so in an 
individual way where HE would be responsible... 

Gotterbam' s interpretation may be right (based, as it is, on closer contact with events), but I find 
n^^ interpretation better given the evidence I have— and the feding, hard to defend, that I am 
reconstmcting events akin to those that led to a messy divorce, the sad end bdng read back into 
all that went bdore. 

" Gotterbam\History of SE Code\History expanded See also Gotterbam Chapter6cmt: "I 
remember the following. Before I left Virginia, in the basement of the house we were staying in, 
via email and phones, there was a discussion about the future of SEEPP. I was given charge of 
SEEPP and the tasking for the three papers before I left." 
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^^ irr Archive, December 18, 1996. In any case, Gotbedem notified eveiyone in SEEPP 
(and its working groups) of his assuming SEEPF s chair (and of his English address) in an email 
of January 6, 1997. 

^^ Gotlerbam\Steering Commitlee\Barben See also Interview of Barber, November 14, 
2002: "I stopped paying much attention to SEEPP sometime in 1996. 1 switched back to software 
from law in September 1995. The career change left me with less time for SEEPP and other 
'extra-curricular' activities — I had to focus on learning a lot of software technology that I 
missed during n^^ five-year excursion into the law." 

*° The (automatic) listserv may have been working on its own Qn January 6, 1997, I 
received this message from Laurie Werth (through the listserv): "I would lite to be added to the 
mail if I am not already on it" 
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Chapter 7: Winter Whirlwind, Version 2 

I bear orders from the Captain: 

"Get you ready quick and soon, 

"We must all be together 

"At the rising of the moon." 

— Irish folk song 

7.1 Statement on codes of ethics 

On January 3, 1997, Donald Gotterbam and his wife Shirlee arrived at London's 
Heathrow Airport. Not sure what to expect of English weather from January to July, they had 
packed one of everything, filling four large suitcases and two carry- on bags. They took a bus to 
St. Pancras Station and there boarded the Northern Express, struggling with their luggage so 
much that the conductor called ahead to Leicester to be sure a luggage handler would be ready to 
help them off the train. An hour later, they were stepping onto the platform at Leicester, a city of 
a quarter million people, once a center for manufacture of knitwear, hosiery, and shoes, now the 
home of many small high-tech companies and two young universities. The station is a short walk 
from the nineteenth- century City Centre and from De Montfort University's Leceister Campus. 
Simon Rogerson was waiting on the platform (along with the promised luggage handler). Having 
greeted them, Rogerson led the way to his car, loaded as much of their luggage as he could while 
leaving room for them, and put the remainder in a taxi. The taxi following, he drove to the 
terrace house, a half mile from campus, where they were to live for the next six months. A light 
snow was falling. The city looked like a postcard. 

On Monday (January 6), Gotterbam arrived at the suite assigned the Centre for 
Computing and Social Responsibility (CCSR) on the tenth floor of the James Went 2. (Went was 
a split-level high-rise. One side of the split was Went 2; the other side, a half-storey down, was 
Went 1.) A gray, rundown, and undistinguished building, marked for demolition early in the next 
decade. Went contained both offices and classrooms— as well as a snack shop and other 
amenities. CCSR's suite consisted of one large open square with desks for a Research Associate 
(Ben Fairweather), three students, and the "webmaster" (a technician who maintained the server 
for CCSR's website). Windows along one side made the open square bright. Having shown 
Gotterbam around, Rogerson led him to the second floor of Went 1 where his office, formerly a 
storage area, was waiting. A (more or less) triangular room with a desk "3-4 feet long", a 
computer, a book case, and two chairs, it was just large enough for two people of modest 
proportions to meet. But it was not without advantages. It had a picture window the length of its 
longest wall, was convenient to toilets and elevators, and had one other advantage, though 
Gotterbam would not appreciate that one for several weeks: As far as DMU was concemed, the 
office was still a storage closet. When Rogerson left his faculty office just down the hall to meet 
with Gotterbam, he (in effect) disappeared from DMU. No one would look for him in a storage 
closet. Indeed, no one but an initiate would look for Gotterbam there either. The two of them 
could work in Gotterbam' s office even for long periods without intermption.^ 
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The preliminaries over, Gotterbam was soon checking his mail on the DMU (desk-top) 
computer.^ A message he had been waiting for— from Cabrera and Frailey— was there. 
Addressed to "Software Engineering Profession Steering Committee, Task Force Chairs, and Ex- 
Qffido Members of the Steering Committee", it formally announced wtet. GotteriDam had agreed 
to two weeks before: 

In order to expedite the remaining activities assigned to this task force, we have asked 
Donald Gotteibam to assume full chairmanship. The task force has the following 
activities to conplete by February 14- 

• complete a draft code of ethics and professional conduct that has its roots in the 
codes currently in use by other engineering professions as well as the codes of the 
IEEE and the ACM 

• document the architecture of this code so that reviewers can understand the 
components, which parts are derived directly from other codes, and which parts 
are specific to software engineering 

• document the rationale for the new parts of the code (those not derived from 
existing codes or which depart from existing codes in substantive ways) 

Other activities for the remainder of the year will be outiined in a plan that Don will 
distribute next week. 

We understand that for a variety of good reasons, many members of this task force have 
been unable to participate at the level originally planned. We specifically authorize Don 
to drive the task force to completion, making whatever changes in membership or 
stinctures are deemed necessary to accomplish this task. 

It was now official. Gotterbam was no longer tied to an IEEE co-chair or to the IEEE standard- 
writing procedures. He was free to act. If SEEPP failed now, he alone would be responsible. 

Gotterbam forwarded the Steering Committee's email to his working group's listserv, 
adding his own covering message. The message's first paragraph announced "some changes in 
the SEEPP task force" and directed readers to the forwarded message from Cabrera and Frailey. 
The second paragraph (in part) explained the new listserv: 

In order to address these tasks [the three listed in the Cabrera- Frailey message] I have 
formed a combined working group [sic] collected under a single email list called prfcmp- 
1. This explains why several of you have received email saying you were added to this 
list. 

Gotterbam then promised to send "a copy of the plan" the next day and "hope[d]" to send "a 
draft statement of the roles and functions of professional codes of ethics... by Thursday [January 
9]." Last, he informed the reorganized "working group" that he was "now working at" CCSR, 
that he had a new email address (dgot(5)DMU.AC.UK), and that the listserv should not be used 
for a message directed to an individual (since many more than that individual would see it). 
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Gotterbam did not make much of it at the time and many, perhaps most of those active in 
SEEPP's work may not have noticed (or cared), but Gotterbam had just reorganized SEEPP. 
Everyone who was not already in Gotterbam' s working group was now in it. Though Gotterbam 
said nothing about the other working groups, a careful reader might have noticed that the name 
given the new listserv implied that Gotterbam' s working group had taken over: SEEPP (the task 
force) had become the "Professional Competence Standards Task Force". The members of the 
other working groups had all been incorporated into one entity which (apparently) Gotterbam 
now indifferently called "working group" or "task force". Gotterbam had abandoned "divide and 
conquer". SEEPP now had the unitary organization of Mechler's SEEPP/E. (Gottembam would 
not again mention the other working groups, except once— in 8.1— to declare them dead. ) ^ He 
had, however, not yet found a replacement for SEEPP itself— (at its best) a small group of 
advisors with v\tom he could meet face to face several times a year. Within a few days, he 
would 

The next day, Gotterbam distributed Version 1 through the listserv. The covering note 
began 'Dear task force men±)er^' (as would all subsequent messages he sent through the listserv). 
The note asked for help with "[annotating] the code with references to similar or idertical 
in^Deratives in other codies"; it promised "a draft of the codes of ethics statement" the next day 
(Wednesday). There was no mention of "the plan" promised the day before (and, in fact, 
Gotterbam had decided not to distribute it until the Steering Committee ^proved).* Gotterbam 
gave no indication of v\ten volunteers should tum in their annotations or how the work was to be 
divided among them (They would, of course, know that they had to get their work in before 
Gotterbarn's deadline, but not the last date before that on which what they did would still be 
useful.) Perhaps Gotterbam expected to set deadlines and divide the work once task force 
members volunteered. If that was what he expected, he was to be both disappointed and 
surprised. 

On January 8 (as promised), Gotterbam distributed the draft "code of ethics statement". 
Its covering note said it was "a brief document describing the roles and functions of codes of 
ethics in an emerging profession" that he wanted "to modify... so that it can provide some 
guidelines for us as we revise the draft code of ethics and determine how next to proceed". 
Gotterbam concluded by inviting "comments on its content and style". Again he gave no 
deadline for response. The statement, about three single-spaced pages, seems intended as a 
summary of everything then known about the functions of codes of ethics (or, at least, of codes 
of ethics in "emerging professions"). But the eight references at the end suggest something much 
narrower. Three of the eight, including two to Gotterbam' s own previous work, are explicitly 
about codes of ethics in software engineering.^ Three more are conpjting-related— Anderson's 
p^:er on the ACM code, Jacques Bedeur' s on the code of ethics of the International Federation 
of Information Processing (IHP), and Johnson's Computer Ethics. The last two references are to 
textbooks in engineering ethics— Johnson's anthology (1990) and Ethics in Engineering by Mike 
Martin and Roland Schinzinger ( 1 989) ! These two represent the best texts in engineering ethics 
of the 1980s, but neither they nor the rest of the references reveal a wide familiarity with the 
literature of professional ethics or even an updating of Gotterbam' s earlier reading in 
engineering ethics. 

Gotterbam was no doubt doing the best he could in the few days the Steering 
Committee's schedule gave him The Committee had, in fact, allowed much less time than a 
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mere counting of days on the calendar would suggest. During his first few weeks in England, 
some time had to go to setting up house, learning his way around campus, and identifying 
resources he would need to draw on latter. His sabbatical leave had two large projects in addition 
to completing revision of the code of ethics. He was to "work up the concept of Software 
Development Impact Statements" and develop a method for "ethical\professional risk analysis". 
He was also making one round trip a week to the United States to teach a ten- week course at the 
National Security Agency (in a Washington, DC suburb), giving lectures in various classes at 
DMU, and preparing papers for conferences. Gotterbam even lost a day or two fighting a virus 
that infected his computer.^ Lite all those in SEEPP (and its working groups), GotberiDam was 
always an ur^Md volunteer, his work on the code having to conq^ete with activities that paid the 
Mis. That was tme even during a sabbatical year. 

Gotle±am' s statement began by noting a "negative standpoint" on the function of codes 
of professional ethics as well as a positive. The negative undeistands codes as "merely a self 
serving atbenq* to generate a positive public image" or "to establish a moral minimum" rather 
than a "conplete" guide to professional conduct While granting that these "negative judgments" 
must be l^t in mind v\ten preparing a code, the writing of a code should (according to 
Gotterbam) focus on the positive functions. The positive functions can be achieved using one or 
more of three sorts of standard: 1) those that apply to everyone in virtue of a common humanity 
(honesty, for exanple); 2) those that apply by virtue of one's special role (or skill) as a 
professional (for exanqie, the obligation to serve society); and 3) those that ^Dply because of the 
special structure of a particular profession. Gotbertam offered no exanple of standards of the 
third sort (in this statement or in the eariier work he referenced) but he seemed to regard such 
standards as (more or less) dedudble from the particular profession's powers, skills, and role 
(just as service to society is dedudble from the spedal role of professions as such). Gotterbam 
also did not indicate v\tether these three sorts of standard correspond to v\tot he elsev\tere 
distinguished as: code of ethics; code of conduct; and code of practice (for exanqie, in his email 
of October 8, 1996, to Frailey).^ Practical (rather than scholarly) considerations seem to control 
v\tot he says here, the most inportant of v\Mch would be satisfying the Steering Committee. 

The core of Gotterbam' s statement is a list (and explanation) of the (positive) functions 
of codes under six headings: 'INSPIRATION", "GUIDANCE", "EDUCATION", "SUPPORT 
FOR POSmVE ACTION", 'T)ETERRENCE AND DISCIPUNE", and "ENHANCE 
PROFESSION S PUBLIC IMAGE". The statement seems designed to lay a foundation not only 
for defending the final code (v\totever its form) but for rewriting Version 1 to mate it more lite 
the ACM's code (v\Mch explidtiy sorted standards according to something lite Gotterbam' s 
three-part plan— with enforcement adding a forth part ). The statement also seems (if less 
obviously) a justification for not connecting the code with licensing. The statement s concluding 
paragr^±is ©qiidtiy limits the software engineering code of ethics to the first four functions. 
The code woiid not be designed for deterrence or discipline (as a code designed for licensing 
would be) because "[at] this stage... , the disciplinary function is being taken over by the law." 
The code would also not be designed to improve the profession's image because "[in] most 
contemporary codes, the attempt to keep a perfect public image at the expense of quality 
development has been abandoned." A code designed neither for disciplining errant professionals 
nor for improving the profession's public image is unlikely to have much use in licensing. 
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By 1997, the most important text in engineering ethics included one function not on 
Gotterbam's list one especially important to an "emerging profession" and the very one Mechler 
had stressed in his exchange with Frailey and Shaw: setting a higher standard than law, market 
and morality would otherwise require.^ The higher standard (a rBquiremerit not an "inspration") 
should if followed, should irrprove the profession.' s image (that is, give it a reputation for doing 
work of a guality higher than law, martet, and morality ask of others). Once a profession had 
such a reputation, government might well want the service the profession provided to be 
provided only by members of the profession (as a way of assuring consumers or public a certain 
level of quality). Might we then wonder v\^ Mechler did not suggest that Gotberbam add that 
function of professional codes?' ° And, since the textbook in question lists me as authority for 
that function of codes, we might also wonder v\^ I also said nothing at the time. Understanding 
v\^ neither Mechler nor I said ariything at the time may help us understand why no one else did 
either. 

One of niy reasons for rx)t resporxling is en±ianassLngly pedestrian: I did not immediately 
receive the email. In those days, I oriy received email at the office. Just after New Years day, I 
had outpatient surgery on the lag toe of n^^ right foot (to fuse two joints). Though not m^or 
surgery, it did mean I had to use crutches for six weeks and could not drive. So, that January, I 
worted at home until the end of winter break (the Tuesday after Martin Luther King Day) . Only 
then did I tate a cab to my office, meet niy class, and check my mail. By that date (January 21), 
Gotterbam's statement was almost two weeks old, stale mail that had to conq^ete for n^^ 
attention first with more recent mail and then with all the demands of a new semester.' ' W ithout 
a deadline, Gotterbam's request for comment had a low priority. Of course, I did put his email in 
my (paper) file, intending to respond. Within a few days, however, that intention drowned in the 
new wave of emails Gotterbam was already preparing. Late January was a bad time to get much 
of a response from me— and perhaps from other academics. 

That was, however, not the only reason I did not respond. I was back in my fly-on-the- 
wall mode, intrigued by what Gotterbam was trying to do and wanting to see what would 
happen. I wanted there to be a code of ethics for software engineers. Without the code, there 
would not be much interest in the process of writing the code (or, rather, trying to write it). 
While I had a fatherly interest in Version 1, it was the interest a father takes in an adult child who 
should be able to prosper on her own. Whatever Gotterbam's errors, they were, it seemed to me, 
not his alone. They were the common wisdom of several decades, and would no doubt continue 
to influence thought about codes for several decades more. There was then no pressing need for 
me to say again what I had already said. There should be other opportunities; writing the code 
had been a slow process. There was, it seemed to me, no reason to expect that to change any time 
soon. Had Gotterbam personally sought my advice (as Mechler had), I probably would have 
responded quickly, but I had no reason to respond quickly to the general call for comment. There 
did not seem to be any deadline (except the date binding Gotterbam, February 14, that residing 
in an earlier email, I did not recall); and there were others, more directly involved, to respond— 
Mechler, for example.'^ 

7.2 Mechler helps 
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Why didn't Mechler respond? Perhaps he did not receive Gotterbam's January 8 email. 
He never mentioned it in later emails and there is no copy in his files. Or, perhaps, he forgot it as 
soon as he saw what it was. His interest was the code, not theoretical discussions of codes. What 
we do know is that Mechler took seriously Gotterbam's request of January 7 for help annotating 
the code (though he did not tell Gotterbam). On January 28, 1997, with the deadline for 
submission of everything to the Steering Committee approaching (February 14), he emailed 
Norman: 

The request from Don, dated 1/7/97, Draft Code, asked for annotation. I am doing a 
number of other codes but have trouble with the one you sent AICPA Standards Manual 
because it was extracts. Can you annotate the Code from the manual? Let me know. 

Two hours later, Norman responded: "I don't have the manual any more. I guess I could 
get it from the University Library again, but I might not be able to get it done in time." Early the 
next morning (January 29, 1997), Mechler told Norman to go to the library only if he wanted 
to— and then, after explaining further why he needed the "exact reference", complained that the 
annotation "is taking forever", asked "Have you heard anything from the list since Don sent his 
last e-mail?", and concluded by setting the "end of the week" as his deadline for "sending out the 
references". By 11:09 AM (after several more messages back and forth), Norman announced, 
"Good news. I have the original that I sent you and it has references to sections and paragraph 
numbers from the AICPA Manual... .Apparently, I'm more organized than I thought!" Mechler 
then suggested that Norman "annotate Dons e-mail of 1/7/97 and put it to the list [that is, send it 
out through PREFCMP-L]. I will do the same with mine." Late that afternoon (after an exchange 
of emails in which each admitted to being "an anarchist", that is, a person not much given to 
keeping orderly files), Mechler returned to Norman's question concerning a deadline: "the only 
dead line I have is Feb 1 4*^. Did you get the additional schedule mentioned in the forward e-mail 
from Don?" 

The next morning Qanuary 30, 1997), Mechler sent his annotations to the listserv 
(PREFCMP-L). He cited five "source codes" (those belonging to the IEEE, NSPE, Project 
Management Instrtute, ACM, and Institute for Certification of Conpjter Professionals). He 
assigned at least one (and up to all five sources) to each of the particular rules. For exanqie, 
under 1.01, he listed "PMI lib— ACM 3.4". Mechler made no attend to provide a source for 
the Introduction or for ariy of the seven general Rules. He prefaced the annotation with a caveat 
A reference may mean that the particular provision of the code is eithen 

Exactly as stated in another code 
Par^ahrased from other codes 
Expanded for SE from other codes 
Idm generators from other codes. 

So, if readers "decide another reference within the codes annotated is better" or "have additional 
codes not mentioned", they should add the reference. But, ariyone v\to disagrees with a reference 
should email Mechler and "we will discuss it'. 
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Mindful of Murphy's best- known "law" ("If anything can go wrong, it will"), Mechler 
waited a half hour and then emailed Gotterbam to see whether the annotations had arrived. 
Mechler also took the opportunity that this email offered to ask two questions he had wanted to 
ask ever since he received Gotterbam's January 7 email: 

1. What was the intent of the statement: "we understand that for a variety of reasons, 
many members of this task force have been unable to participate at the level originally 
planned." In Felipe and Dennis e-mail you forward[ed] to us? 

2. What is the plan for the rest of the year they requested in the same e-mail. I do not 
know if you sent anything yet. 

Mechler also emailed Norman to see whether he had received the annotated code. About noon, 
Norman responded that he had received it. Sure that all was well, Mechler went on to other 
things. But the next morning (Friday, January 31), he received a message from Weil at IIT: 
"SOS. The Code of Ethics annotated toward other codes was not attached. Instead came the 
words 'Unable to print this part'." Mechler investigated and responded about twenty minutes 
later: 

It is something to do with the list. I am on the list twice using CompuServe and Exchange 
and both came with warning about MIME. But I received both. Here is another copy. Let 
me know if you received it. 

Having sent this message, he wrote PRFCMP-L: "There appears to be some problem with the 
SEEPP List sending my annotated copy of the Code. If you didn't get it, please let me know at 
emechler(5) ero.eqt.com." 

Seven minutes later (about twenty-four hours after Mechler first sent his annotations), 
Gotterbam emailed the list a message with a table attached (comdes.doc). According to the 
message, the table not only incorporated Mechler' s annotations but extended them to seven other 
codes. A half hour later, Mechler responded: "Can not open comdes.doc. Please resend or send 
as a text file." Mechler also emailed Norman directly asking whether he was able to open 
Gotterbam's file. Norman took a half hour to reply: "My VMS mail cannot read MIME either. 
However, I can convert it to text with PINE and I will send you a copy." An hour after that (still 
January 31), Gotterbam notified the list: "The attachment seems to have some problems :-)"^^ 
WMleyou are reading and commenting on the tome I sent, I will try to get this table straightened 
out (he said hopefully!)" Gotterbam did not solve the protiem until late Sunday (February 2). 
Early Monday morning he wrote PRFCMP-L: 

Sony about the problems with the early version of the table. Only one person (with a 
MAC) was able to read it To avoid all difficiilties with versions or word processors etc. I 
spent a pleasant ground hog day (a special holiday in the colonies) rebuilding the table. 

Tuesday morning (Febmary 4), Mechler had some bad news for Gotterbam (using 
PRFCMP-L): "In the second version of code relationships [comdes2.doc] the references do not 
line up with the correct code. It ^Dpears as spaces, tabs, etc. were not included Nothing lines up 
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under IEEE or PMI. Norman quickly emailed Mechler directly: "Mine seems to be reasonably 
lined up; at least readably so! Here it is." What lined up for Norman did not line up for Mechler. 
After several more exchanges, Norman realized that the problem was not visible on his computer 
screen because of the font used. Everything lined up using the default font, Courier, but not using 
any font having variable spacing. He advised Mechler to print using Courier. "If that doesn't 
work for you, let me know and I will get a printout with Courier and fax it to you." But, Norman 
added, waiting for the fax might mean waiting till tomorrow because he would have to use his 
home PC: 

I do not have immediate [access] to the right combination of resources right where I 
am— Our VMS prints to a lineprinter, and the stuff in labs is occupied by hordes of 
students who always succeed in breaking things. We have the equipment, but to get a 
working combination of monitor, disk drive, and printer in the middle of the semester is 
quite an achievement here! 

Norman had figured out what the problem was and had told Mechler— but not the listserv 
(or Gotterbam). Norman and Mechler seem to have forgotten that they were working "off the 
list"— or, perhaps, it did not occur to either of them that Gotterbam might also be working on the 
problem. But Gotterbam was working on it and, on Febmary 5 (Wednesday), he wrote Mechler 
triumphantly: 

The copy of the code you sent me lined up on my system, standard IBM clone. I checked 
with someone else here and they had no problem either, so I thought maybe something 
flipped going across the atlantic and I check[ed] with someone else in the states. They 
didn't have a problem either. Let me know your fax number and I will send you a hard 
copy of the table. 

Mechler sent the fax number, saying nothing about Norman's discovery of the day before and, 
indeed, without any message at all. Did this unusual curtness mean that Mechler was too busy to 
chat (or that he had had enough chatting about the attachment)? While we cannot answer that 
question, we can be pretty sure that the reason Mechler sent the fax number was that Norman's 
discovery had not solved his problem and Mechler wanted to see Gotterbam' s table. Gotterbam 
nonetheless had to put off sending the fax. The Went Building had (he soon learned) only one 
fax machine, requiring a code and authorization to use. Rogerson, who would have had to 
authorize Gotterbam' s use, was out of town. So, instead of faxing, Gotterbam kept working on 
the problem. By the next moming (Febmary 6), he had remade Norman's discovery (or, rather, 
confirmed a hypothesis Ben Fairweather, the philosopher, had posed). ^^ Gotbedem first wrote 
Mechler directly and then informed the listserv, adding new details: 

TTietalie is pure asdi text taMeardniList be printed using a rnono-space font, something 
exciting lite courier :-). Copy the table onto your word processor, select the table, select a 
mono-space font v\Mch does not cause the table to wr^. If there is nothing under PMI 
for 1 .01 then the table is wr^Dpang. This should work for most systems that I know of. 
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Norman confirmed a few minutes later (using the listserv): "Yes, I discovered that. Any of the 
courier fonts works fine with it in MS Word." Early Friday (February 1), Mechler also 
confirmed (using the listserv): "Thanks everyone. I finally got a lined up copy of the matrix. 
Thanks Don." It had taken exactly one week for three experienced software engineers (two of 
them still practitioners) to get comdes2.doc to print properly on Mechler' s equipment. 

7.3 Comparing codes 

The table was worth the effort. Below is the first part of it the imperatives under Rule 1 
and their sources (Rule 1 having the fewest sources). (For the entire table, with legend, see 7. 
Appendix.) 

[Insert] 
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The rationale for choosing just these twelve codes is not obvious. All are American or 
British. Why none from the rest of Europe? Why none from Latin American, Australia, or 
Canada? All the engineering codes are American (unless, following the British, we count the 
BCS's as an engineering code). Why not even one (other) engineering code from Britain (say, 
the code of the Institute of Electrical Engineers)? 

There is another oddity. There are two ACM codes where there should be one. The 
ACM-G (the commentary on the Code of Ethics and Professional Conduct) includes the entire 
ACM Code of Ethics (ACM). In this respect, the ABET Guidelines (ABET-G) differ from the 
ACM-G. Not only is it a document separate from the short ABET Code of Ethics for Engineers; 
it is also missing some parts of that code (specifically, the Fundamental Principles). Like the 
NSPE's code of ethics, the ACM code does not seem (properly) divisible into code and 
independent guidelines. 

The codes divide neatly into six for engineering (AAES, ABET, ABET-G, ECPD, IEEE, 
and NSPE) and six for computing (assuming the Project Management Institute is primarily 
concerned with managing software projects). But two engineering codes seem odd choices: The 
AAES code (American Association of Engineering Societies, Model Guide for Professional 
Conduct), though adopted in 1984, was almost forgotten by the mid-1990s. It is one of those 
"failed codes" no one would want to copy. The ECPD "code" (Faith of the Engineer, Engineer's 
Council for Professional Development) is a one-page "creed" adopted in 1948 by what later 
became ABET. It was never intended as a code of ethics. The ECPD adopted its first (and very 
successful) code of ethics in 1947 ("successful" insofar as most major engineering societies 
adopted it within a few years of its publication).^^ ABET let The Faith of the Engineer (the 
"Faith") die quietly. What did Gotberbam hope to achieve by citing it? He did not say. The 
obvious answer is political: give engineering the same number of codes corrpiter science had 
But peiii^DS there is another expLanatron. Both the 'Taith" and AAES code ^Dpear (on facing 
pages) at the back of the Martin and Schinzrnger text'^ Their presence in that book may have 
misled Gotberbam about their inpjrtance. He expressly dtes that text as the source of "[m]ost of 
the [engineering] codes".'' There is other eviderce for this explanation: all six of the engineering 
codes Gotterbam cites (and only those) appear in Martin and Schinzinger (1989). Gotterbam's 
dependence on that text would also explain why no British code of engineering ethics is cited, 
though codes of the British Computing Society are.'^ The Martin and Schinzinger text includes 
no non- American codes. 

If this explains Gotterbam's choice of engineering codes, then we are entitled to draw 
two conclusions. The first is that neither Gotberbam himself nor those with v\tom he was 
worldng at CCSR knew much about engineering codes. If engineers (and their philosopher 
friends) dominabed "SEEPP\E", now conpjber scientists (and their philosopher friends) were 
dominating the work of the reorganized SEEPP. The second conclusion is that Gotberbam 
probably lacted the time to find out v\tot he did not know. He had a tight schedule. The only 
convenient library (DMU' s) lacted a recert American text on engineering ethics. And there were 
then few, if ariy, websites displaying codes of ethics. 

While I am also tenqied to explain the absence of codes of ethics other than those from 
engineering and conpjting in the same way, I think there is a sinqier alternative. Gotberbam 
may have been inberpreting the Joint Sbeering Commitbee's request (January 6, 1997) that he 
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"document the architecture of this code so that reviewers can understand the components, which 
parts are derived directly from other codes, and which parts are specific to software engineering" 
as implicitly asking only about computing and engineering codes. That is not unreasonable for 
two reasons. First the Committee's immediately preceding request (its first) was even more 
limited ("complete a draft code of ethics and professional conduct that has its roots in codes 
currently in use by other engineering professions as well as the codes of the IEEE and the 
ACM")}^ Second, precedents closer to software engineering would naturally cany more weight 
than precedents more distant Every clause had precedents close to software engineering. 
Gotle±am had no reason to look fuitiier. He must not have known that until late in the process, 
though. Had he known that earlier, he would, presumably, have made clear that volunteers 
should only look at codes related to engineering and conqxrting (and so saved Norman and 
Mechler the trouble of recovering notes onthe AICPA code). 

Whatever reason there is to criticize the choice of codes, the overall message of the table 
is plain (as even the part reprinted above suggests). Version 1 seems to correspond most closely 
to corrpiting-related codes: ACM's and PMI's. That no doubt is— as Gotterbam points out in 
his comments— because the inq^eratives under Rule 1 concern software (with v\Mch ACM and 
PMI are specifically concerned). Yet almost every inq^erative also has at least one "engineering 
hit'. Contrary to v\tot Frailey and Shaw argued. Version 1 was not in substance, all that 
different from existing codes. It therefore is not liMy to be less practical than these. The one 
way in v\Mch Version 1 seems to differ from the others should be an advantage. Version 1 covers 
more than any other single code does (though not more than all together). Gotterbam could, it 
seems, have treated Version 1 as v\tot Cabrera and Frailey had asted to have delivered by 
Febmary 14, a "draft code of ethics and professional conduct that has its roots in the codes 
cunentiy in use by other engineering professions as well as the codes of the IEEE and ACM." 
Nothing in the table, or in the comments so far received from the working group, required a total 
rewriting or restmctuiing (rather than a series of nairov\dy targeted amendments). What did seem 
to, if anything did, was the prgudice against Version 1 that the premature criticism of Frailey 
and Shaw may have generated within the Steering Committee (5.6). 

Gotterbam' s table (the attachment) came with both a one-page single-spaced covering 
letter and (following it) a two-page single- spaced document bearing the very long titie: 

Revision of 

DRAFT DOCUMENT RELATING 

COMPUTING, ENGINEERING, AND SOFTWARE ENGINEERING CODES. 

v2 30 Jan 1997 
The Architecture of the Draft Software Engineering Code of 

Ethics and Its relations to other Codes of Ethics 

The authors of this document "Gotterbam & Rogerson", must have begun it at least a few days 
before January 30, but they must have revised it on January 30— after Mechler' s annotations 
arrived The third paragraph says that "the commitiee" (not "the working group" or "task force") 
"examined other codes of ethics including. . ."^° The list of six items includes WJ. King's The 

Unwritten Laws of Engineering, the AICPA code, and the PA State Registration Board's code. 
The list is plainly Mechler' s, but nonetheless differs from his list of eight in three ways. First the 
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NSPE code is not there?^ The reason for this difference seems to be that the preceding paragi^ii 
had already identified the NSPE code's stmctuie as the model for Version 1. There was no need 
to mention it again so soon Second, the Institute for Certification of Conpjter Professions 
(ICCP) Code of Ethics is not there (even though it is one of the twelve in the t^e) . There seems 
to have been no reason to omit the ICCP code— except that it added little to the variety of 
sources already listed. Third, the list is not quite in Meclier' s order Mechler had the IEEE code 
first and the ACM code fourth. Gotterbam & Rogerson moved the ACM code to first place. 
Alphabetical order does not seem to explain this change. If the order were alphabetical (as it is in 
the table of codes), the AICPAP code would come second, not fourth; the PMI code would not 
be third; and so on. The reason for putting the ACM code first seems to be political. So far, 
oppDsition on the Steering Committee had come from two ACM-^Dpointed members (Frailey 
and Shaw). Putting the ACM code first here might "help the medicine go down". 

Overall, the statement on "architecture" seems designed to introduce Version 2 (though 
the first use of "SECEv2" is not until the seventh paragr^ii) . Thus, the first paragr^ii begins: 

This document was developed in response to a request for the lEEE-CS/ACM Joint 
Steering Committee for The Professionalization of Software Engineering. The 
architecture of the draft Software Engineering Code of Ethics (SECEvl) has been 
modified in the light of comments from the software engineering and corrpiter ethics 
communities. 

The fourth paragr^ii, after reporting that "the commitiee" had distributed SECEvl to others for 
comment, says that "in light of those comments and further work by the committee, the stmcture 
of the code has been revised to reflect significant aspects of otha: engineering and corrpjting 
codes." The remaining eight paragr^±is describe SECEv2. So, for exanqie, after noting that 
"[many] codes" such as the British Conpjler Society's and the ACM's include "a preamble 
descriiing the roles and functions of the code for the practicing professional", it indicates that 
"[the] stmcture of SECEvl has been revised in accordari:e with this model". 

Though most of the document on architecture follow closely Gotterterri s eariy p^:er on 
functions (for exanple, using SECEvl to illustrate his "three levels"), it does report two 
surprises. First, the original purpose of constmcting the table ("documenting the architecture") 
had been to "show v\Mch parts [of SECEvl] derived from other [engineering and conpjting] 
codes and v\Mch parts are urdque to software engineering." That purpose presunied that ttere 
"clear lines of demarcation between engineering, conpjting, aid software engineering." The 
table is "not consistent with that presunption." None of the inq^eratives is unique to SECEvl, 
and virtually every inperative has a counterpart both in some engineering code and in some 
corrpjting code. Mechler had been right (5.6) Second, there is nonetheless an interesting 
contrast between engineering codes and conpjting codes: "At the moment some irr^^eratives are 
contained mostly in engineering codes (the outer columns of the chart) and [some] inq^eratives 
are contained mostly in conpjter codes (the inner columns of the chart)." Those in^^eratives 
sparsely represented in both engineering codes and conpjter codes concern "management 
issues" or "very specific. . .technical issues in software engineering." 

The covering letter (January 31, 1997) preceding the document on code architecture 
began with thanks to "those v\to commented on rr^^ draft on Functions of Codes of Ethics and 
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who contributed to annotating the code... especially Ed." This explicit thanking of Mechler 
seems right but it does suggest two questions. First who else contributed to the comments or 
annotations?^^ Second, v\tot in fact was Mechler' s contribution? What did Gotbertem mean 
when (in paiagi^±i 2), he said he had "integrated Ed's results into the baseline document [the 
table]"? We can be confident that someone other than Mechler did contribute. Mechler had 
provided annotations for five codes; the table covered twelve. Norman's annotations did not 
arrive in time (and would, in ariy case, not have fit the engineering-conpjting plan) . Who did the 
work for the other seven codes? The answer may be: Gotberbam His general practice seems to 
have been to thank explicitly ariyone v\to did airy significant work He had special reason to 
thank some others if he could, for exanqie, his host, Rogenson We must therefore suppose 
Gotberbam to have analyzed the seven codes more or less by himself.^ ^ What else must he have 
done? 

We know that Mechler found analyzing five codes to be taxing, even v\ten the work was 
spread over several weeks. We must then assume that Gotberbam spread his work over several 
weeks as well— or, at least did not do everything in the twenty-four hours between the time he 
received Mechler' s annotations and the time he sent the table out But if Gotbertem worted on 
the table for several days or weeks before Mechler' s annotations arrived, he was unliMy to have 
armotabed just the codes Mechler omitted Gotberbam did not know v\tot Mechler was doing, or 
even that Mechler was doing anything, since Mechler did not tell him Gottertem, in turn, did 
not tell Mechler there was a deadline for the work if Mechler (or other contributors) wanted their 
work to be of use; and, indeed, there may have been none (^:art from Febmary 14). Gotberbam 
seems to have worted as fast as he could; the table was just one of several substantial projects 
soon to be revealed So, ty January 30, he must have had an almost conqiete table for all twelve 
codes. He would have included the codes Mechler did (v\tere there was overly) for the same 
reason Mechler included them: they were too inpjrtant to omit (and, except for the ACM, PMI, 
and ICCP codes) were included in the Martin ard Schinzinger text on which Gottertem relied). 
So, the arrival of Mechler' s annotations must have been a conplete (and unique) surprise. Their 
late arrival meant that they could provide no more than a check against Gotterbam' s own work.^ * 
Had Mechler been a little slower, his work would have been entirely wasted (as Norman' s was) . 
Gotberbam was no longer moving slowly, waiting for others to do something. Those used to his 
patient style did not and probably could not have, anticipated v\tot Gotberbam did in January— 
or v\tot te would do over the first two weeks of Febmary. 

The rest of Gotberbam' s January 31 letber was a status report Paragraph 3 promised to 
"[revise] the Functions paper in light of your comments". Paragraph 4 reported that Gotberbam 
"[is] fortunabe to be at the Centre for Conpjting and Social Responsihality this semester, v\Mch 
is supplying both intellectual and clerical support of this effort Paragraph 5 lays out a "tentative 
[six-step] plan" (without dates): "1. [Submit] a revised code to the steering committee for review 
and comrnent 2. Revise the code in light of the comments, 3. Print the Code in the ACM and 
IEEE publications with a survey asking for comments and voting on each item", and so on The 
paragraph ends with the promise that a "more detailed plan is forthcoming". 

7.4 The plan to revise 
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On February 4, 1997, Gotterbam addressed a sixteen- page (single- spaced) memo, "Dear 
EC (executive commiti;ee)".^^ The "executive commitiee" had just three membens: Gotterbam, 
Miller, and Rogerson The executive committee formalized what had become Gotterbam' s 
practice over the two weeks preceding— working closely with Miller and Rogerson, both of 
whom responded quickly to calls for help and seemed to Gotterbam to know v\tot they were 
doing. Why Gotterbam tiought it necessary to formalize his "kitchen catanet" is a niystery. As a 
formal body, the executive committee looks unbalanced three relatively senior academics, all 
conpjter scientists without ariy background in engineering.^^ Though all had considerable 
experience in industry, that experience would not have been obvious to anyone looking at 
affiliations (and, in ariy case, was experience as "software engineers", not engineers strictiy so 
called). Since Rogerson was not an American, he gave the EC an international flavor) and since 
he was in information management, he might also seem to offer a management perspective (as 
indeed he did). But Miller was almost Gottedem's twirt an American professor of corrpiter 
science. 

The first paragr^ii of the Febmary 4 memo explains that v\tot follows is "a copy of the 
code" (Version 1) with comments integrated The source of each comment is indicated by 
initials: DF (Frailey), MS (Shaw), ED (Mechler), and so on Most of the commentators are 
familiar from Ch^ier 5, but two are new: sr (Rogerson) and DS ("second pass comments" from 
Gotterbam and Rogerson— 'D" for 'Don" and "S" for "Simon"). Some of the comments "raise 
difficulty" because "they are based on a miss-reading of the code" or are "just plain wrong" (for 
exanple, Shaw' s view of "bribery as good international business practice"). Tbe task of the EC 
is "relatively quickly" to restructure the code "a to inprove it, b. to address otgections raised, 
and c. [to] put together changes suggested with reasons for each and circulate to the task force." 
Gotterbam then stetched his own ideas for irrproving the code: 

A.preamble introduction 

i. revision of the introduction to include v\tot we consider main functions of code 

ii. indication that code is not a list, black letter law, as in BCS code— put in 

preamble 
iii. mate clear stmcture based on relationshipe^' 
iv mate clear that client & errployer may not be synonymous, may even mean 

professor and student 
V. include all people related to SE, lite academics 
vi. YOUR ADDmONS OR DELETIONS FROM THIS UST 

B. ligger issues 

i. need to clearly bring QUALITY into the code— maybe in places that mention 

efficiency, forexanple L13 replace "productivity" with "quality" 
ii need to bring in teamwork and management issues 
iii. a professional owes higher order level of care 
iv. relate all stateholders not merely "end users" 
V. address "intensity issue" by replacing "assure" with different terais 
vi. YOUR ADDITIONS DELEHONS FROM THIS UST 

C. minutia 

i. change "RULES" to "PRINCIPLES" 
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ii. will we interleave examples 1.1,1.2 into list of principles, NSPE model or make 

the examples a separate list of guidelines ACM model, 
iii. Y OUR additions or deletions from this list 

Clearly, Gotterbam has gone beyond resolving the issues that Frailey, Shaw, and members of the 
task force had raised the preceding autumn. Who, for example, had asked whether "client" might 
mean "professor" or "student"?^^ 

Even the two (substantive) "minutia" suggest that Gotterbam was planning to rewrite the 
code in ways that went well beyond the criticism received in October aid November. Both the 
"minutia" are inpjrtant changes in aichitectuie. The change from "rules" to "principles" is not 
merely the substitution of a three-syllable word for a one-syllable one. It also substitutes a more 
amtaguous temi for a less amtaguous one. I had called the general standards "lules" to stress that 
they were as handing as the particular standards, merely more general forms of the same sort of 
standard; I had used "shall" in them rather than "should" for the same reason For marry people, 
"principle" suggests a standard of a different kind from "rule", for exanple, a starriard that 
should have weight in deliberation, not— lite "mle"— one that, while open to interpretation, is 
binding, something one either obeys or violates.^ ^ 

While Gottertem seems unaware of this possible understanding of "principle", he would 
soon (Febmary 10) offer his own suggestion for distinguishing between "mle" and "principle": 
"these [the Rules] are not really single rules but statements that embody a set of activities. This 
change [to Principles] lessens the possitality of misreading of the code as a checWisL" Since all 
mles embody a set of activities, Gotterbam has not actually explained the distinction He has 
sinqiy offered the name "principle" as a better way than "rule" to lessen the liMihood that the 
starilards in question will be used as a checklist What reason he had to believe that the change 
of name would actually acconplish that end he did not say.^ ° 

Similariy, segregating the particular standards ("exanples") in a separate section, as the 
ACM code does, might (as Gotterbam also claims) lessen the liMihood that the Principies will 
be used as a check list But it might not Other outcomes seem equally probable. For exanple, a 
separate section for the principles might invite hasty users to forget about the particular starilaids 
altogether or suggest that the particular standards be treated as mere commentary rather than as 
tnnding rules, something to look at only if one has doubts about v\tot a principle on the "check 
list" means. 

That GotteriDam would describe such architectural changes as "minutia" is surprising. 
The "minutia" in question might well mate the difference between a code widely used and one 
soon forgotten. GotteriDam' s later extensive reworking of the code, v\totever its merits, seems to 
show that he did not regard these issues as "minutia". Perii^DS "minutia" is no more than an 
unfortunate "slip of the pen" (or v\totever the word-processing equivalent is). That Gottertem 
would mate errprical claims about how the code is likely to be used without evidence is not 
surprising (even if interesting). Though we know little about how codes of ethics are used, 
claims about the heuristic advantages of writing a code one way or another are common (and, in 
n^^ experience, often wrong— or, at least inplausible upon examination).^' 

7.5 The great revision 
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The next few days would have been hand for Gotterbam even without trying to straighten 
out Mechler's table. Gotterbam, apparently with much help from Rogerson, rewrote the entire 
code (drawing on responses received in October and November), annotated the changes, sent the 
annotated revision to Miller and Rogerson for comment, and revised accordingly. Since Miller 
was in Illinois, not working down the hall (as Rogerson was), we have some idea when 
Gotterbam completed Version 2. On the moming of Febmary 10, Miller sent in his last 
comments (responses to Gotterbam' s replies to his earlier comments). Some reveal how 
important Rogerson was. For example. Miller had found several provisions with "outwith" in 
them and confessed to not knowing what the word meant. Gotterbam had responded, "Simon's 
contribution— a scot[t]ish idiom, meaning 'standing outside of. He thought it would add an 
intemational flavour to the code and determine if anyone read this far." Miller's Febmary 10 
reply is: "HA, HA... I passed the test! Intemational flavor or intemational obscurity?"^^ Writing 
a code of ethics, though serious woric, need not be solema 

Some of MiUei^ s comments reveal the process of choosing words by v\Mch a code comes 
into being. For exanqie. Miller had commented (on the always troublesome) 1.14 ("Avoid 
fads. . ."): "Are you going to include a citation to a handbook of 'standard' software engineering 
practices. I want that reference." Miller's request for a reference was, of course, ironic. The 
Software Engineering Institute was, in effect, working toward such a handbook piecemeal. Any 
handbook was (as Miller knew) decades away (and, lite engineering handbooks, would never be 
conqiete or entirely up to date). The Body of Knowledge Task Force would, at best, offer only 
relatively uncontrovensial standards as part of the "body of knov\dedge" all software engineers 
share (a basis for identifying those v\to know the "basics" rather than for guiding the 
experienced). Some practices might, though popular, be novel enough not to belong in the body 
of knov\dedge or even in SEI standards and yet not be v\tot ariyone would understand as a fad 
Gotterbam therefore answered Millen 

We have stmggled with that one. . .We received m^ or attacks on "fads" . 

Perh^DS answer your "standards" question in terms of "what is publicly 
defensible" or in terms of results from the skills task force. I know neither of ttese is a 
good answer, but they are answers other technologies would use in defending that a 
practice was 'standard' . 

Ary ideas how to reframe this point? 

Miller's February 10 suggestion is to rewrite 1.14 to read (something lite): "software engineer 
should follow industry practice that, in his/her judgment, are most ^Dpropriate for the task at 
hand Novel and experimental techniques may be ^Dpropriate, but not for the sate of novelty." 

That evening, barely a month after he arrived in Leicester, Gotterbam sent the task force 
(an annotated) Version 2 of the "Code of Ethics for Software Engineers". Having had enough 
trouble with attachments v\ten he sent out the table of code references, Gotterbam did without 
attachments, dividing his message into three emails (none large enough to clog a standard 
mailbox). The first was a page-long covering letter with "Principles 1-2"; the second, "Principles 
3-4; and the third, "Principles 5-7". 

The division into parts did not work quite as planned Gotterbam sent off his emails just 
before 7:00 PM Leicester time. By 6:00 PM (EST), that is, several hours later, Norman used the 
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listserv to tell Gotterbam he had all three (February 10, 1997).^^ Next morning, howiever, Milton 
Fulghum (Missouri) emailed (throng the listserv): "I have received parts 1 and 2 but not three." 
About noon (February 11, 1997), Langford (Kent, two hours by train from Gotterbam) sent a 
similar respjnse to Norman (through the listserv): "O fortunate one— I managed to get (2) and 
(3), but am still anxiously waiting for (1)..." Late that afternoon, Gotterbam advised 
"patience. . . [the] net being whst, it is, the messages are taking interesting routes to get to you all." 
He gave one exarr^e to make the point: 

I mailed them [the three emails] from the Centre for Con^Duting and Social 
Responsihality here in England The director [Rogerson]— office across the hall from 
me— did not get part one until 2:00 pm this aflemoorL...[v\Mle] a research associate 
[Fairweather] upstairs had all three this morning (GMT). 

Gotterbam urged everyone to "tackle, grapple with, the parts you do have :-). I ^Dpreciate your 
enthusiasm, but we are actually slowing down their arrival filling the net with these messages 
(me too, I guess with this message) ." 

By the next morning, everyone v\to had ariy part of the tri-partite message had all three. 
But there was at least one problem of another kind, the mailing list itself. Weil emailed 
Gotterbam (Febmary 12, 1997): "I don't understand why my colleague Michael Davis has not 
received the recent flood of e-mail. We thought csep(a)chariie.cns.iitedu was on the [list]." 
Gotterbam responded that "[Davis] has always been on the list as weil(a)chariie.acc.iti:.edu [sic] 
and is still on that way."^ * He recalled "we were having some trouble with his address last year 
and . .per instmctions we changed his address to yours, only at .ace." Gotterbam then promised 
to change the address if it was now not worMng. He went on to say that he "would ^Dpredate his 
comments and yours on the current version of the code and our plans"^ ^ and concluded ty asking 
"Are you still backing us for NSF?"^ ^ 

Once conqiete, the tri-partite message was an irrpessive, even if inconqiete, document 
It was seven single-spaced pages long. Mariy of the code' s seven "Principies" or specific clauses 
had braclffited numbers inserted (1-19). Each number corresponded to a comment at the back of 
the email (with numbering beginning at 1 in each email). Each number either marted a change 
already made or identified a place v\tere a change was "under constmction". The comments 
explained a change and sometimes provided a justification (though some of the Principles also 
hsd explanations preceding them). There was no 'Introduction" because "changes to the 
Preamble are being worted on now." 

The covering letter (Febmary 10, 1997) not only explained these matters and urged 
everyone to read through the draft "in the next few days" but to "give us your comments" and 
"your suggestions for inpDvements". The letter also included two substantive paragr^±is 
explaining Version 2' s architecture. (These paragraphs used the future tense, suggesting that they 
hsd been pulled from an eariier planning document without editing.) The first described "v2.0" 
as having an architecture "similar to version 1.0." It "will start out" with a "preamble or 
introduction explaining the code and [providing] guidelines on its use."" Following the 
preamble wUl be "a series of teyword principles descrihang a software engineer^ s obligations in 
a variety of relationships." (Apparently, v\tot Gotterbam meant ty "teyword principle" is v\tot 
most people would call a "titie" or "teyword".) Associated with each teyword is a "high level 
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description of the software engineer's obligations [what Gotterbam elsewhere calls a 
'principle']." Following each of these is "a series of clauses detailing some of the obligations 
under this Principle." These obligations "are taken from all three levels of obligations in a 
professional code of ethics" (human, profession as such, and software specific). Gotterbam had 
not reworked the Code to mirror the three levels. 

The second paragraph calls this architecture of "major principles followed by 
explanations or examples... fairly common." It then gives two carefully chosen examples to 
prove the point: "it is used by the NSPE and the British Computer Society". The mention of the 
British Computer Society protects Version 2 from being treated as an engineering- style code 
rather than a computing- style code (or as an American-style code as opposed to an international 
code). While politic, the claim that Version 2.0 resembles other codes in this way is only very 
roughly true. Version 2.0 (and its predecessor) are alone (at least among the codes Gotterbam 
discusses) in explicitly treating the particular mles as examples (special cases) of the general mle 
under which they are listed. In most codes having particular mles listed under a general one, the 
relationship is left to interpretation. Also "quite common", according to Gotterbam, is the use of 
the preamble to inform users that "the code should not be considered as a complete list of 
professional ethical obligations", for example, "all codes in the architecture table follow this 
format". In fact, that is not tme of any of the engineering codes cited— though it is certainly 
reasonable to interpret them as having such a provision "implicit". ^^ Version 2.0 (and its 
predecessor, 1.0) had, in this respect, joined a relatively small number of recent codes (of v\Mch 
the ACM and BCS codes are two inp^rtant exanples). 

Code 2.0 (and, presumably 1.0 as well) "differs from most codes" in "its use of teyword 
principles". Most codes do title their m^or sections (though some, lite the 1979 IEEE code) 
merely give "reference titles" such as "Article I", "Article 11", and so on Some, such as the 
Australian Corrpjter Sodely Code of Ethics, also have "teyword" titles (such as 'T*riorities", 
"Con^Detence", and so on) and general standards (such as "I will serve the interests of n^^ clients 
and eriqioyers, my enqioyees and students, and the community generally, as matters of no less 
priority than the interests of n^^sdf and rry colleagues") as well as particular rules under them 
(for exanqie, "I will endeavour to preserve the continuity of conpjting services and information 
flow in my care").^ ^ The "SE code differs [from other codes, according to Gotterbam,] in that its 
keywords are tied to professional relationships". This is inpjrtant because "[works] on corrpjter 
ethics have found this organization [by professional relations] useful in covering the topes of 
professionalism and useful as a nmordc [mnemonic] device."* ° 

The comments suggest that Version 2.0 is, overall, a less demanding ("more 
asprational") document than Version 1. In many respects, that is tme.*' So, for exanple, 
comment 6 notes that "Strive to" has replaced "Assure that they" in 1.02 ("Strive to understand 
fully the specifications for software on v\Mch they worlc") to "placate those v\to ^Dpeal to 
inpjssiMity of precise specs"; and comment 10 notes that "Aspre to" has replaced "Assure that 
they" in 1.12 ("Aspire to identify, define and address ethical, economic, cultural, legal, and 
environmental issues") as part of a general program to use a "more asprational and intentional 
phrase in these level 1 type obligations in 1.10-1.14."*^ Again, 2.02 ("Approve software only if 
they have a well-founded belief that it is safe, meets specifications, and has passed ^Dpropriate 
tests....") is the result of three amendments: One substituted "well-founded" for "well- 
documented". The second deleted the word "all" before "appopriate tests". The third substituted 

174 



"appropriate" for "proper". Note 15 points out the first change but does not explain it. For 
software engineers bedeviled by lack of documentation, the substitution of "well-founded" 
reduces Version I's overall emphasis on documentation. A programmer need only think she has 
good reason to approve; she need not document her reasons. When a question arises a year later 
and she is gone to another job (or forgotten what she thought at the time), how will anyone know 
what her belief was— what she considered "safe", what she thought the specifications were, or 
what tests (if any) she thought "appropriate"? Similariy, note 15a explains that "all" was deleted 
"to avoid the suggestion that exhaustive testing is required" (just what Mechler thought had been 
avoided by having "as appropriate" precede all clauses under Rule 1). But, in avoiding the 
"suggestion" of exhaustive testing (a standard generally too high to be practical), the deletion of 
'air had the effect of permitting a software engineer to do no more than some appropriate 
testing, something short of all the tests that should (together) be done.^^ 

Though the overall tendency of the proposed revisions was to mate the code less 
demanding (more "asprational"), some changes seem to add to its demands. For exanqie. Rule 
2.05 ("Be fair and tmthful in all public statements") had become "Be fair and tnjthful in all 
statements, particulaiiy public ones, concerning software or related documents." Comment 18 
explains that, as originally written, 2.05 "indicated that it was ok to lie in non-public statements" 
(on the questionable but not unknown interpretive principle that v\totever is not expressly 
foriidden is allowed).** Comment 18 ^Dparently overlooks v\tot the code's introduction says 
about the status of particular rules. They are instances of the general rule. So, for exanple, 2.05 
is an instance of "2. PUBLIC Software engineers shall, in their professional role, act only in 
ways consistent with the public safety, health and welfare." Ary non-public statement 
inconsistent with the public safety, health, or welfare is also disallowed What the revised 2.05 
seems to disallow (that the original did not) are non-public lies concerning software or related 
documents that are consistent with the public safety, tealth, and welfare. For exanqie, 2.05 now 
seems to disallow lying in non-public statements to tyrants or unscrupulous enployers even 
when such lies serve the public safely, health, and welfare. A software engineer must be 
"truthful" even with them Since Principle 2's 'In particular^' has no "as ^Dpropriate", Version 
2.0 therefore sets a higher standard than Version 1 . 

Some changes that seem intended to raise standards may in fact lower them Consider, for 
exanple, comment 8 under Principle 3 (Judgment). The comment notes the need for some 
"social clause" in 3.06 ("Participate in no decision of a governmental or professional body, as a 
men±)er or advisor, concerned with software, or related documents, in v\Mch they, their 
enployer, or their client has a financial interest"). "[As] this clause stands judgment is merely a 
technical thing and does not involve social issues." The comment then offers the following as 
possible substitutes for 3.06 (^Dparenfly intending to raise the standard): 

Only mate judgments v\Mch can be publicly justified as being in the best interest of 
quality of life, and the environment 

All technical judgments should be tempered and guided ty the need to support and 
maintain human values. 
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Be aware that all technical judgments impact other human beings. They have 
stakeholders other than employers, clients, and users. 

Gotterbam seems to have understood that 3.06 (and, indeed, all of Principle 3) is concerned with 
maintaining independent professional judgment (that is, avoiding conflict of interest), not with 
substantive issues discussed elsewhere in the code.'^^ What he does not seem to have undenstood 
is v\^ it is inpjitant to have a separate section on technical judgment after two sections 
("PiDduct" and "Public") concerned with the very substantive issues he proposes to incorporate 
into 3.06. The avoiding of adverse financial interests is a means of helping to ensure that the 
judgments in question "can be publicly justified as in the best interests of quality of life" and are 
"guided by the need to support human values". Substituting the general imperative for a 
particular means, allows the end to be pursued by other means instead (for example, by giving to 
the poor some of the profits derived from keeping the adverse financial interests). The point of 
3.06 is that there is no substitute for avoiding this sort of conflict of interest. Good intentions 
(and even compensatory good deeds) are not good enough. Gotterbam' s recourse to good 
intentions as a substitute for the flat prohibition of certain conflicts of interest is thus a 
weakening of the code even though intended to strengthen it. 

Some changes are hard to categorize on the dimension of more-or-less demanding 
because their overall effect is hard to gauge. For example. Version 2.0' s Principle 1 has "free of 
error" where Version 1 had "free of significant error." The comment on this change explains that 
"[we] felt uncomfortable with the phrase... It might be used as an escape clause— 'I had lots of 
errors but didn't think any of them significant'. "We" tried to compensate for this strengthening 
of the code by specific changes in Principle 2 ("PUBLIC Software engineers shall, in their 
professional role, act only in ways consistent with the public safety, health and welfare.") But 
there "is still some concern with this change [deleting "significant"] because it is not possible to 
write error free code. Any suggestions for balancing these concerns?" The overall effect of this 
combination of changes may or may not be a change in what is actually demanded. What seems 
clear is that Gotterbam, Rogerson, and Miller ("we") are aiming at something very close to the 
balance that "free of significant error" was intended to achieve. (Eventually, they would seek to 
achieve that effect by radically different language.) 

Other changes are hard to assess on the more-or-less demanding dimension for other 
reasons. For example, the third change in 2.02 substitutes "appropriate" for "proper". The 
explanation for this change (here and elsewhere in the code) is that "appropriate" is "less vague" 
than "proper". There are "technical answers to the question 'which methods are appropriate?'"— 
but, apparently, not to the question, "Which methods are proper?" Many readers may find the 
claim that "appropriate" is less vague than "proper" novel and suppose that all that has happened 
is that a "$3 word" has replaced a shorter one. Others may suppose that technical standards set 
what is "proper" but interpretation (professional judgment) must decide what is appropriate. 
Given that supposition, the change from "proper" to "appropriate" would be a weakening of the 
code (a substitution of individual judgment for common standard) rather than (as the comments 
claim) a strengthening. Some word must be chosen, and all will be open to misinterpretation. The 
most precise word is, all else equal, the best. But what makes a word the most precise? And how 
are the drafters of any code to know?" 
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Another example of hand-to-assess changes is the general replacement (in Principle 1) of 
"assure" with "ensure" (where "assure" is not replaced by "strive" or some other less demanding 
term). But here the claim to know which wonl is better relies on a linguistic authority (the 
Oxford English Dictionary). Comment 3 (under Principle 1) defends the replacement as a 
weakening of the obligation: "'ensure' is less legal than 'assure' which carries a formal 
guarantee and legal connotation (according to the OED); whilst 'ensure' means to strive to make 
things happen and no formal guarantee is implied."^^ Appeal to the OED may seem parochial. 
An American v\to looks up "ensure" in Webster^ s (or one of its American conipelitois) will find 
the eriby under "ensure" to be: "same as insure" (a formal legal guarantee); or "make sure or 
certain" (something distinctly stronger than "strive to make happen").*^ So, in the US at least, 
replacing "assure" with "ensure" may not weaten the obligddon (or even avoid the hint of 
formal legal guarantee). If anything, the replacement strengthens the language, substituting the 
robustly otgective "ensure" for the faintly psychological "assure". And, in fact, I had chosen 
"assure" over "ensure" because I did not want to suggest "insure". I too was concerned to avoid 
the suggestion of "formal legal guarantee". What I had overiooted is that code- writers almost 
urdveisally prefer "ensure" (even if they do not know v\^). Here, as in many other places, there 
is agreement about the end in view in the choice of a certain word but disagreement about the 
meaning (or liMy inqsct) of the word in guestion More, interesting, though, is that OED 
entries for "ensure" and "assure" are similar to Webster' s.* ^ The OED does not in fact ^Dpear to 
explain the preference for "ensure" . Did anyone on the EC actually check the OED? 

Amid all these changes in wording was one hag stmctural change. The third part of the 
three-part email proposed to add a v\tole new section, "Principle N Management" ("N" being a 
placeholder until tte new section received a number detemnning its place in the code). The 
principle itself was only partly stated: "A software engineer in a management or leadership 
cspddty shall...." But under this half-stated principle are nine clauses (N6.06-N6.15). Most, 
such as N6.06 ("Assure that employees are informed of standards before being held to them"), 
are sinqiy pulled from the clauses under Version I's Principle 6 ("Colleagues"). Some are 
slightly revised For exanple, N6.13 differs from Version I's 6.13 only in having 
"remuneration" in place of "condensation" ("Offer only fair and just remuneration"). (The 
explanation for this change is that "in Europe [ 'con^Densation' ] means 'an item given to redress a 
wrong done you'".)^° One clause is entirely new ("N6.15 Not ask an employee to do ariything 
inconsistent with this code"). Preceding the particular clauses is a warning that they are "under 
constmction". Clauses yet to be formulated should include "enable, encourage, follow good 
practice", "provide direction to good software engineering practice", and something about 
'Team building. Communications, and Good practice". These clauses never entered ariy version 
of the Code.. 

The idea for a distinct section on supervisors, managers, or leaders may have come to 
Gotteitem from one (or more) of five sources. First, Gottertem understood the code to be 
organized according to "relationships". Management is an inportant relationship, one software 
engineers regularly find problematic. Insofar as Gottertem's understanding of the code's 
architecture is the source of Principle N, Principle N is evidence that theory can mate an 
inportant contribution to writing a code (by calling attention to an option that we might 
otherwise overtook) . Second, GottertDam may have gotten the idea for Prtndple N from the ACM 
Code. Unlite most other professional codes, it has a section on "Organizational Leadership 
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Imperatives". While Gotterbam may have gotten the general idea from the ACM Code, he does 
not seem to have drawn anythin more specific idea from it. None of Principle N's clauses seem 
to share language with any of the imperatives in the ACM code's (large) leadership section. 
Third, another possible source of Principle N is Rogerson. He had a special interest in the ethics 
of technical management. Fourth, the list of rules under Principle 6 had become significantly 
longer than any other. It therefore invited the question: can we divide this in some way? Fifth, 
and most probable, Gotterbam may have gotten the idea from Milton Fulghum, a SEEPP 
volunteer. Fulghum suggested dividing Rule 6 in just this way in his comments of October 22, 
1996. Among the computer files Gotterbam retrieved from George Washington University after 
his arrival at DMU was Fulghum' s email.^^ 

7.6 Why the new Gotbeitem? 

Just two days before the deadline Cabrem and Fiailey had set Gotbe±am to deliver "a 
complete draft of the code of ethics and professional conduct", Gotterbam was sending off for 
comment a draft much rougher than the one he had started with— a code lacking a preamble, 
differing in many important ways from its predecessor, with some provisions still "under 
constmction, and the whole untested by outside comment"— , a code no more "[rooted] in the 
codes currently in use" than its predecessor but now salted with question marks." Once a distant 
administrator, punctuating long silences with a new plan others were to follow and then waiting 
quietly for them to follow it, Gotterbam had suddenly become active, inventive, and daring. He 
was doing much of the work himself. He was not singly revising the code to meet otgections but 
rewriting the code as he thought it should be written. He was betting that he understood the 
politics of the Steering Committee, and of the two organizations that had joined to create it, well 
enough to undertate fundamental revisions at v\tot must have seemed rdther late in the game.^ ^ 
What explains this change in the way Gotterbam worted? We may identify at least three (more 
or less) related possible explanations (in addition to having the more flexible schedule of a 
sabbatical leave). 

First, Gotterbam seems to have begun his co-chairing of SEEPP somewhat in awe of the 
lEEE-CS. At his first meeting with Barbacd and Mdford, he had accepted the IEEE' s standard- 
setting procedure, the organization by task force and working group, and even a list of working 
groups having little relationship to lis previous experience hdpng the ACM write its code of 
ethics. That, in the mid-1990s, a conpjter scientist would, all else equal, defer to engineers on 
how to organize a large-scale project is understandable. The reason for coining the term 
"software engineer" almost three decades earlier was precisely to point up the superior 
organizing ability of engineers, to invite programmers, computer scientists, and the like to leam 
from engineers how to organize a large project, how to complete it on time, within budget, and as 
specified. In addition, the joint project had begun as an exclusively lEEE-CS undertaking. ACM 
had joined after the Steering Committee had begun work. Less clear about what it wanted the 
project to accomplish, the ACM had not demanded that its procedures be followed. Gotterbam 
had begun work in what must have seemed an engineering environment. He needed time to leam 
his way around, to see the limits of the IEEE method, and to gain the confidence of the lEEE-CS 
appointees on the Steering Committee.^* 
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Second, once organized, SEEPP could only work (Gotterbam supposed) if he and 
Melfond agreed. Gotterbam could not act on his own (except as leader of his working group). 
Melford could prevent Gotterbam from acting simply by falling behind in answering his email. 
He had a (unintended) "silent veto". While Gotterbam accepted the IEEE's standard- setting 
procedures, including the division of labor among working groups, and Melford had time to 
meet, the requirement that the co-chairs agree did not matter much. SEEPP was able to produce 
the documents that the IEEE procedures called for— at something like the rate typical of the 
IEEE standard- setting process. However, once Melford' s business began to overwhelm him, 
leaving him less and less time for outside activities, his "silent veto" became important. However 
much Gotterbam doubted the value of the complex stmcture to which he had initially consented, 
it was now something he could not change unilaterally. He could not even (he supposed) 
properly email SEEPP, much less call a meeting, without Melford' s express consent. He was like 
a fish in a frozen lake. When Melford resigned as co-chair, the lake thawed. 

Third, Gotterbam could work on his own through his own group. Professional 
Competence, but he could work there only within the group's limited mandate. His working 
group could not write a code of ethics (or a code of professional practice), only a part of it 
("avoid generalization of expertise, keep current, keep staff current, tmth about skill, what 
should be produced, appropriate knowledge base").^^ What Gotbeibam did ask, v\Mch was all 
that he could ask, did not much intea^st many of the volunteers. They slov\dy drifted away. 
Though he could see what was h^Dpening, he could (it seemed) do nothing about it As SEEPF s 
co-chair, he had to be careful ^ut organizational etiquette. If he ignored Melford, or just 
offended him, he might alienate lEEE-CS, risking the entire undertaking. Mechler succeeded 
v\tere Gotterbam failed precisely because he ignored the organization in a way Gotterbam could 
not Qr, rather, Gotterbam could succeed within the stmcture he had accepted only by using a 
device familiar to software developers, the "skunkworks", that is, "a group of people v\to, in 
order to achieve unusual results, work on a project in a way that is outside tte usual rules."^ ^ Had 
Mechler not rushed in on his own, Gotterbam would have had to invent him Once Melford 
resigned, there was no need for a skunkworks. The Steering Committee, having teamed to trust 
Gotterbam, gave lim tlie power to create a stmcture within v\Mch lie could work He tlien 
worlffid more or less as Meclier liad, tliough within the rules and with a speed even Meclier 
never exlihated 



179 



7. APPENDIX: Comparison of Version 1.0 with Other Codes 



From: IN%o"PRFCMP-L(a) UTKVM1.UTK.EDU" "Professional Competence Standards Task Fo 
roe" 3-FEB-1997 07:10:33.22 To: IN%"PRFCMP-L(a)UTKVMI.UTK.EDU" "Multiple 
recipients of listPRFCMP-L" CC: Subj: Text version of table 

Return-path: <(5)uga.cc.uga.edu:owner-prfcmp-l(5)UTKVMl.UTK.EDU> Received: from 
uga.cc.uga.edu by minna.cns.iit.edu (PMDF V5.1-4 #19448) with SMTP id 
<011EYYFUVB5C8ZK3P4(a)minna.cns.iit.edu>forCSBURNSTEIN;Mon, 

Sony about the problems with the early version of the table. Only one person (with a MAC) was 
able to read it. To avoid all difficulties with versions of word processors etc. I spent a pleasant 
ground hog day ( a special holiday in the colonies) rebuilding the table. 



Explanation of the table: The first column refers to sections of the SECvl. Only those items 
which closely matched the statements in SECvl are referenced. If the referenced item in the other 
code is almost a direct quotation, then the reference appears in single quotes. 

The codes used for comparison, listed in alphabetical order, are: The American association of 
Engineering Societies, Model Guide for Professional Conduct(AAES); Accreditation Board for 
Engineering Technology's, Code of Ethics for Engineers (ABET C of E) and Guidelines for The 
Fundamental Cannon of Ethics (ABET G); The Association of Computing Machinery's Code of 
Ethics(ACM), and Guidelines for Professional Conduct(ACM G), The British Computer Society 
Code of Conduct (BCS C of C); The British Computer Society , Code of Practice(BCS C of P): 
The Institute for the Certification of Computing Professionals (ICCP); The Engineer's Council 
for Professional Development, Faith of the Engineer(ECPD Faith); The Institute of Electrical and 
Electronics Engineers, Code of Ethics(IEEE C of E); The National Society of Professional 
Engineers, Code of Ethics for Engineers (NSPE C of E), and the Project Management Institute 
"Code of Ethics for the Project Management Profession" (PMI). Several of these codes did not 
contain section and paragraph numbers, so the following reference procedure was followed. If 
the document was not divided into sections, its paragraphs were simply numbered sequentially 
starting with 1. If the code was divided into sections and paragraphs. The paragraphs were given 
an alphabetical designation and the paragraphs within each section were numbered sequentially 
starting with 1. Most of the codes are in Ethics in Engineering, Martin and Schinzinger, 
and the other codes are on the NET Reference Table Comparing Software Engineering Code v 
1.0 to Other Codes of Ethics, version 1.0 January 1997 Software Eng. C of Evl: 
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*****TEMPORARY ADDRESS CHANGE****** Don Gotteibam Centre for Conqxiting and 

Social Rfisponsilility DeMontfoit University, School of Conpjting Sciences Leicester LE 1 

9BHUK 

From IN%"PRFCMP-L(a)UrKVMI.UrK.EDU" "Professional Con^^etence Standards Task Fo r 

with spool id 5129 forPRFCMP-L@UrKVMl.UrK.EDU; Mon, 03 Feb 1997 09:17:10 -KXXX) 

Date: Mon, 03 Feb 1997 14:15:14 -fOOOO From Donald Gotterbam <dgot@DMU.AC.UK> 

Sutgect: Re: Code Annotation In-reply-to: <c=US%a= 

%I>=EQT%l=ERIXCHANGE-9701301453512-8 Ed As regards the schedule, I did draft a 

detailed schedule for conqietion of the project as was requested by the Steering committee. Until 

that schedule's details and the requested support are ^proved by them I did not fed it was right 

to distribute it widely, but instead listed in general terms those steps v\Mch I hope will lead to a 

successful conqietion of our tasks. 

I understand your concern and ^predate your enthusiasm but I did not want to distribute 

arrything v\Mch was not agreed upon 

regards, don 
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NOTES 

^ Gottedam Email (Febmary 12, 2004) AtlachmenL 

^ Gottejtem's coirpiter arrangements were more conplicatEd than this description 

suggest "I had ir^^ l^Dbop— which was a faster machine than the one supplied by DMU, so I 
brought it eveiy day aid did niy woric on it I would then either transfer the data to the DMU 
machine and send it Ch: I would go horne in the evemng and use rnyniodem to connect and send 
messages." Gottertem Email (Febmary 12, 2004), Attachment Hence, Gotterbam could send 
and receive email from home in the evening or on weetends. 

^ SEEPFs working groups had, of course, long since ceased to matter) ariyone who did 

notice the reorganization was uriliMy to care. Gottertem therefore had no reason to enqliasize 
the reorgardzatiorL Conpare GotteriDam "I formed a single committee consisting of the Prof 
Conpebence people and the working groups leadens from the other groups, hopng they would 
bring their functioning groups men±)ens along with them PRF-Conp was just a mailing list a 
tool that was there and that was useful. It existed so it was easy to add people to the mailing list 
There were no hidden motives!! You make something of nothing. I did a conplete 
reorgardzatiorL A Single purpose group for single -clear task assigned by steering committee. 
If I had a functioning mailing list latied 'h^Dpy day' I would have used it" Gotteibam 
Ch^Dter6cmt (October 31, 2004). 

^ See email from Gotterbam to Mechler (Febmary 3, 1997): "I did draft a detailed schedule 

for conqietion of the project as was requested ty the Steering Committee. Until that schedule's 
details aid the requested support are ^proved ty them I did not fed it was right to distribute it 
widely, but instead listed in general terms those steps vMch I hope wUl lead to successful 
conqietion of our task." This seems to me to be a charge in the way Gottertem (and Gotterbam- 
Mdford) had operated until 1997. Gottertem-Mdford had often announced schedules without 
Steering Committee ^jproval. What explains the change? "By getting approval for a plan," 
Gotterbam suggests, "I could proceed full speed ahead without asking permission at every turn." 
Comments on Ch^Dter 6 (September 23, 2003). Why did Gotterbam think he would otherwise 
need "pennission at every turn"? The Steering Committee has already authorized him "to drive 
the task force to conqietion". The Steering Committee had also said he would distribute the plan 
"next week" but not that he needed ariyone' s permission to cany it out "Other activities for the 
remainder of the year will be outiined in a plan that Don will distribute next week." 

^ The two references to Gottertem's own work are his entry, "Software Engineering 

Ethics", intbe Encyclopedia of Software Engineering and one of the papers he gave at PASE'96, 
"Software Engineering: the new professionalism". 

^ Actually, GotteriDam gives the publication date of Johnson's anthology as "1996" rather 

than "1990" (a typo or perh^:s a misreading of a handwritten "0" as a "6"). The first edition of 
the Martin and Sclinzinger text came out in 1983; the second edition (1989) was basically the 
same book. Both references were, then, substantially less current than the stated publication dates 
suggest 
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^ Comments on Ch^Dber 6 (September 23, 2003). GottederrivGottedem memories of 1997 

(9\1\2003). 

^ "I was not writing for scholariy consimpliorL For details on this [his scholariy views], 

see n^^ 'The Moral Responsitality of SofbA/are Developers: Three Levels of Professional 
Software Engineering,' Thejouranl of Information Ethics 4 (Spring 1995): 54-64." Comment 
on Chapter 7 (September 21, 2005). 

^ Charies E. Harris, Michael S. Pritchard, and Michael J. Ratans, Engineering Ethics: 

Concepts and Cases (Wadsworth: Belmont, 1995), p. 38 (a code of ethics as the solution to a 
coordination problem, something more than just a guide to individuals). 

'° Was Gotteibam aware that Mechler might otgect to the omission of standard-raising? 
Probably not, though he certainly had another opportunity to become aware of it Four hours 
after sending off the statement, Gotterbam got his George Washington email account to forward 
to his DeMontford address Mechler' s respjnse to Shaw. He did this, it seems, as part of a larger 
effort to collect all comments on the code before preparing his revision That same evening he 
retrieved the comments of Frailey, Fulghum, Langford, and Prinzivalli in the same way. (Two 
days later, he also retrieved Shaw' s original message.) 

'' There may have been an additional delay. At this time, my name had (again) dropped 
from Gotterbam' s list. Any email I received from Gotterbam was a copy Weil passed on— after 
checking to see if I had received it independently. 

'^ In his comments on this ch^Dter (September 23, 2003), Gotteitem raises a question of 
professional ethics: 'Don't you wonder about the moral resp^nsihalities of MD here?...Certainly 
he had responsiMity as a professional to address that [that is, to correct v\tot I considered 
Gotterbam' s omission of an inpjrtant purpose of codes]." The question is worth answering here 
because it underscores the difference between the (1980s) theories of professional ethics 
Gotterbam took for granted and the theory I developed in opposition to it (and v\Mch, apparently, 
he was not aware of even in 2003). My position is that I have no obligations "as a professional 
[as such]" , only as a men±)er of a particular profession (or as a moral agent, parent, promisor, or 
other particular relationship). What is n^^ profession? I'm an academic, a member of the 
professoriate. Thaf s my only profession; philosophy is the discipline I practice, but not niy 
profession (a special way to earn a living). To decide what my obligations as an academic are, I 
start with the code of etiics of the American Association of University Professors. I don't find 
ariy requirement there that an academic must correct every error ariyone mates with respect to 
his discipline, not even that an academic should correct every error a colleague (or student) 
mates. There may, of course, be obligations the code overiools (the unwritten ones that derive 
from the written or have some other origin). But, ariy claim for one of those requires an 
argument— and, in this case, I believe there is none. What Gottertem seems to have in mind is a 
general obligation to be a Good Samaritan I think there is no such general professional 
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obligation. For more on this, see my Ethics and the University (Routledge: London, 1999), 
Chapter 4 ("Science: after such knowledge, what responsibility?"). 
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In 1997, ":- )" was stiU all that printed, though the meaning was a smile: 



'* Comments on Ch^Dter 6, September 23, 2003. Gotteibam later added: "One of the 
reasons for the dday [in recognizing that the problem was in the kind of type the printer used] is 
no one of us consideiBd that an ascii table would be printed using anything but a fixed font We 
did not look for the problem here because we thought people knew better. When it was thought 
that this might be the issue, it was stated in a way not to embanass aiiyone." Gottedem 
Ch^Dtei6cmt, October 31, 2004. 

^^ For a decade or so (until the mid-1960s), the ECPD code had the endorsement of most 
American engineering societies. The NSPE' s code is its direct descendent (and the ABET code, a 
radical reworking of it) . 

' ^ ScMnzinger was a professor of engineering already close to retirement when he teamed 
with Martia a young philosopher, to do the first edition of their popular text He might well have 
remembered tte Faith from his youth and suggested its inclusiorL 

" Febmary 3, 1997: "Most of the codes are in Ethics in Engineering, Martin and 
Schinzinger, arid [sources for] the others are on the NET Reference Table Conparing Software 
Engineering Code v 1.0 to otto: Codes of Ethics, version 1.0 January 1997 Software Eng. C of E 
vl". 'TMost" is both a (gross) understatement and a (slight) overstatement The six codes from 
Martin and Schinzinger are fl// the engineering codes but only half of the total (counting codes as 
the table does). 

'^ Getting a copy of the code of dhics ("Ethics Policy") for British engineering, for 
exarrqie, for the Institute of Electrical Engineers, was then, and remains, difficult Only someone 
teaching a course in engineering ethics in the UK would be liMy to have one easily available. 
Codes of ethics for conpjting are much more accessible in the UK. My concern in noting wtet. 
Gotteibam did not do is not to say he should have done more (under the conditions), but to be 
clear about wtet. he did do (and therefore about wtet he did not do), facts relevant to assessing 
the changes he made. 

" Gotteibam's Comments on Chapter 6 (September 23, 2003): "I guess we didn't do all 
those other things because we were paying attention to the TASK assigned- show that the draft 
code has roots in engineering and corrpiting. Not law, medicine etc. The tasks as assigned 
were difficult enough to get done in the time frame without adding to the task" Exactiy. 

^° This use of "committee" may be a mere "slip of the pen", but it may also be the first 
reference to the executive committee soon to be formally announced in the "Proposed Schedule". 
SeeCh^DterS. 
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^^ TMs, of course, is the only omission from Mechlei^s list of eight (originally sent 
December 19, 1996, but resent January 30, 1997). I am, of course, assuming here (for the reasons 
given in 6.9) that the December email never reached GotiErbam 

^^ The guestion here is not who else contributed suggestions for revising the code. There 
were many (Frailey, Fulghum, Kanko's students, and so on, but not Mechler). Instead, the 
question is who provided comments or annotations concerning the "roots" of Version 1 in other 
codes. 

^^ "Thanks for the credit— but Simon and Keith were always there." Gottertem 
Ch^Dbei6cmt, October 30, 2004. Yes, they were "there", Rogerson in person (v\ten not out of 
town) and Miller by email. So, they certainly might have helped in constmcting the table (hence, 
n^^ hedging "more or less") . But no evidence survives of their participation in constmction of the 
table— and neither of them actually recalls hdpng with it— though there is plenty of evidence of 
their hdpng on almost everything else. So, it seems to me, Gottertem really does deserve the 
credit I have given him ("more or less"). 

^^ Gotierbam otgects to this interpretation: 'TMs is wrong— I do remember being greatly 
pleased by the work he provided That is v\^ I mentioned him specifically! GIVE HIM 
CREDIT! He was still woridng on the Code. YOUR THEORY MEANS I MUST HAVE UED 
GIVING HIM SPECIAL THANKS." Gotteri^m Ch^Dter6cmt (October 31, 2004). While I do 
not mean to suggest that Gottertem is here telling even a white lie, I do think his words give a 
misleading inp^ssion of v\tot h^Dpened (however unintended). That Gotterbam now 
remembers being please v\tot Mechler' s contribution is consistent with its merely providing a 
check on v\tet Gottertem had already done (and with Mechler deserving the praise Gottertem 
gave him at the time). The timing seems entirely against Gotterbam' s claim that (in effect) five 
columns of the table are Mechler^ s work, not his. 
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GotierbamWersion l\Cmntster. 



^ ^ Gotierbam otgects to my characterization of the executive comrrdtijee: 'It was a software 
engineering code— Miller an academic— does contracts for NASA etc., lots of experience on 
practical and academic side: same for Rogerson and Gotterbam" Gottertem Ch^Dter6cmt 
(October 31, 2004). Tme enough, but in addition to not being obvious to anyone v\to just looks 
at their institutional affiliations, these gualifications would, even if obvious, not satisfy an 
engineer that the perspective of engineers would be understood Gottertem' s criticism of this 
passage assumes that "software engineers", even if fully gualified to work on software, are 
necessarily engineers, an assun^Dtion most engineers would tten (and even now) rgecL 

^ ' Gotterbam here misstates Version 1' s stmcture. Five of Version 1' s Rules (Public, Client 
and Enqioyer, Profession, Colleagues, and perti^:s Self) are "relationships" (in some sense) but 
the other two (Product and Judgment) certainly are not (or at least not in the same sense). 
Indeed, the long section on "product' is something unusual in codes. I had created it singly to 
hold a lot of suggestions not fitting any other category. I constmcted Version 1 "from the bottom 
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up" (ignoring the relational or function structures of earlier codes); Gotterbam was constructing 
Version 2 "from the top down" (or, at least wanted the Steering Committee to think of the code 
in that way). Seeing what I had done, he assumed I had worked the same way. In fact my 
intentions (or method) could not be read from the results achieve (the code itself). 

^^ Gotlie±)am' s comments on the first draft of this ch^Dber (September 23, 2003) resp)nd to 
niy question "Who but an academic would ask that?"— "An academic who had actually read 
various international Corrpjting codes of ethics— lite the Australian Conpjler Society's code 
which specifically mentions students." The academic who actually read the code in question is 
not a h5TX)thetic academic, presumably, but Gotteibam (and peihaps the other membens of the 
EC). So, it is worth pointing out that v\ten I chected the ACS's code at 
http//www.acs.org.au/national/pos|p^:eiyacsl31.htm (September 23, 2003), I found a code that 
mentioned "students" (here and there) but never "professors". Its section 4.3 (Values and Ideals) 
is typical: "I must act with professional responsibility and integrity in my dealings with the 
community and clients, enqioyers, enqioyees and students." The idea of specifically mentioning 
"professors" (as well as "students") may haave arisen from GotieriDam' s wide reading in codes of 
conpjting ethics and his wide experience with conpjter ethics more generally. What it did not 
arise from is ariy of the criticism he had so far received from ariyone (or, at least ariy that have 
survived on p^:er), even from criticism coming from professors and students— or from the code 
he actually dted 

^^ See, for exanqie, Ronald Dworldn, Taking Rights Seriously (Harvard University Press: 
Cambridge, Massachusetts, 1977), esp. pp. 14-80; or the Walt Disney movie. Pirates of the 
Caribbean (2003), in which pirates unwilling to follow "The Pirate Code" when they should, say 
(something like), "Well, its not so much a rule as a guideline." 

^ ° GotberiDam' s otgection to "checklists" presupposes an answer to the prior question: what 
is wrong with using a code of ethics as a checklist? Using the code in that way certainly seems 
better than not using it at all (because, say, one does not know where to start and does not want 
to take the time to find out). Using the code as a (complete) checklist is a somewhat different 
matter. It too is better than nothing but definitely not as good as asking, after going through the 
checklist whether there might be something the checklist should include but does not— or 
something that one should consider whether a code could include it or not. No doubt there is 
something wrong with a question such as this: "Sexual harassment is prohibited, but what sort of 
harassment is not?" 

^' For a critique of some of these claims, with references, see my "Three Myths about 
Codes of Engineering Ethics", IEEE Technology and Society Magazine 20 (Fall 2001): 8-14 & 
22, reprinted (with some revisions) in Profession, Code, and Ethics (Ashgate: Aldershot 
England, 2002), pp. 121-132. 

^ ^ GotberiDam' s memory of these events differs a hit from v\tot n^^ reconstmction: "When 
worldng hard marry of us— ME— lite to jote a lot I inserted Simon's phrase ["outwith"] in 
several places just because of the reaction I knew it would draw from Keith. Simon did have a lot 
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to do with the Code, but this phrase was just a break from the work." Comments on Chapter 6 
(September 23, 2003). So, according to Gotterbam, it was his joke, not Rogerson's. This joke 
was the one piece of evidence I came across that anyone but Gotterbam could change the text on 
his own, even as a joke. 

^^ "The way email is processed in pactets explains the other phenomena below. Again I 
tried to treat the frenzy caused by lack of knov\dedge about pactets in a light hearted way. So I 
described the most extreme exanple and then suggested we move on and not further crowd the 
bandwidfli" Comments on Ch^Dber 6 (Seplen±ier 23, 2003) 

^^ Actually, all addresses with "weil" were Vivian Weil's. I had a series of addresses with 
"csep" (or the c^tahzed version) before the "@", because I wanted CSEF s secretary to receive 
and print rr^^ email. My addresses were: csep(a)chariie.cns.iitedu (1996-97); 
csep(a)chariie.acc.iitedu (1995-96); and csep(a)irrA/AX.BrmKr (1994r95). The old addresses 
forwarded to the new addresses for a time, adding to the confusion, especially since IIT generally 
"migrated" addresses in batches, not all at once, and "csep", being near the beginning of fte 
alphabet would be "migrated" well before "weil" near the aid What was h^Dperdng at IIT was, 
of course, happening elsev\tere as well. Within a month or two of the day on v\Mch Gottertem 
first put his Ust together, it was probably out of date and, no matter how hard he tried, it was 
probably never up to date again. Cutting-edge technology cuts both ways (making a job both 
easier and harder). 

^^ Gottertem considers this email a "an explicit request for comment" (Comments on 
Ch^Dter 7, September 21, 2005). I do not The request is, of course, not addressed to me directly, 
but to Weil (since it was part of email atten^Dted to get me back on the mailing list); it came after 
Version 2 was conplete (and as part of attempting to send it out for generaly comment); and it 
laclffid the specific questions Gottertem had addressed to members of his executive committee 
or DMU's inner circle. These considerations do not excuse me from commenting; they just 
addressthequestionof v\tether was aslffid to comment (and on what). 

^^ If Gottedam's transcription of n^^ address is correct, the problem was sinple but easy to 
miss, the confusion of "iir (correct) with "itt" (incorrect). In general, email addresses require a 
perfection that postal addresses do not In addition, during these years, email addresses changed 
much more often than postal addresses because they contained information about specific servers 
("chariie" or "VAX"), admirdshative departments ("ens" or "ace"), and program ("BrmKT") 
now generally omitted Maintaining the address list turned out to be a permanent undertaking 
more demanding than teepang a p^:er list current So, for exanple, sometiing lite the February 
12 exchange occurred again ort Marh 27, 1997 (Gotteatam to me, checking to see v\tether I got 
v\tot he sent); April 7, 1997 (from Gottertem to me, "you have been added to the PRFCMP-L 
mailing list"— with detailed instmctions); April 24, 1997 (from Gottertem asking for name, 
address, e-mail, and so on to "update database"); and April 29, 1997 (from me to Gotteatiam, 
thanking Gottertem for putting him back on the list but reporting that Weil, 
weil(a)chariie.cns.iitedu was now off). 
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^^ Gotte±)am never explains the switch from 'Introduction" to "Prean±ile". I had chosen 
'Introduction" as a terai less ponpous than "Preamble" (and in keeping with Mechler's initial 
choice). 

^^ Tte enorisjust one indication that Gotteiteni had prepared this memo in haste. An^ 
is his description later in the paiagi^±i of a preamble not yet written as if it were included in the 
document sent: "The code also differs from other codes by cleariy addressing, in the prean±ile, 
the difference between the three levels of professional obligation and organizing tte clauses 
under each principle around these three levels." The code never was so organized (and the 
preceding paragraph had admitted as much). Gottertem's thinking seems to have got a little 
ahead of lis editing. That is not surprising given how much he did in his first five weeks in 
England What is inpjrtant, if not surprising, is how his thinking about the Code seems to have 
been evolving as theories espoused for years met the practical difficulties of writing a code. 
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* ° GotieriDam gives no reference for this statistical claim My random examination of a few 
conpjter ethics texts failed to confirm it GotteriDam's Comments on Ch^Dter 6 (September 23, 
2003) responded to this observation: "You claim that your readings fail to find any evidence for 
this claim is telling- Try reading the most influential book written on Corrpjter Ethics- in the 
third edition now-'Conpjter Ethics' by Deborah Johnson- the point about professional relations 
is in all three editions." I then chected Deborah G. Johnson, Computer Ethics (Prentice- Hall: 
Edgewood Cliffs, New Jersey, 1985). What I found was a book with six chapters not much 
different from other computer ethics texts I checked. The chapter titles were: Ethical Theory; 
Professional Ethics; Liability for Malfunctions of Computer Programs; Computers and Privacy; 
Computers and Power; and Ownership of Computer Programs. The text was not organized by 
relationships. However, Johnson's chapter on professional ethics does contain a section, pp. 26- 
30, on " Professional Relationships" subdivided into four "relationships" (Employer-Employee; 
Client or Consumer-Professional; Professional- Professional Relationships; and Society- 
Professional). There is no claim there (or elsewhere in the book) that these relationships cover all 
the topics of professionalism or even that they are useful as a mnemonic. Johnson makes no 
pedagogical claim whatever there. So, it seems, Gotterbam still lacks authority for his statistical 
claim. And, in any case, the software engineering code is, as explained above, only partly 
organized according to "relationships" (at least, relationships of the sort Johnson distinguishes). 

*' Qr, at least, is tme if we ignore the intended effect of the premising "In particular" 
clause. In many, perhaps most, instances, the conduct intended in Version 1 and Version 2 was 
probably much the same. The problem was finding the best words to achieve that effect (with 
only our knowledge of English to guide us). A "user lab" would have been a great help in 
preparing this code of ethics (or any other). 

^^ 'Tevd [or type] 1 obligations" were those that ^Dplied to humans as such (that is, moral 
obligations). Why ttey should be more, rather than less, asprational is not stated. Generally, we 
consider moral obligations (the universal ones) to preempt merely professional ones. That 
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"generally" indicates some controversy concerning whether professional obligations may 
(occasionally) preempt moral ones. See, for example, two advocates of professional obligations 
as preempting ordinary morality: Benjamin Freedman, "A Meta- Ethics for Professional Morality," 
Ethics 89 (October 1978): 1-19; and Alan Goldman, The Moral Foundations of Professional Ethics 
(Rowman and Littlefield: Totowa, NJ, 1979). For some important criticism of this "separatist 
thesis", see: Paul R. Camenisch, "On Being a Professional, Morally Speaking," in Moral 
Responsibility and the Professions, eds. Bernard Baumrin and Benjamin Freedman (New York: 
Haven Publications, 1983), pp. 42-60; Alan Gewirth, "Professional Ethics: The Separatist Thesis," 
Ethics 96 Qanuary 1986): 282-300; and Michael Davis, "The Moral Authority of a Professional 
Code", Authority Revisited: NOMOS XXIX (New York University Press: New York, 1987), pp. 
302-337. 

^^ October 6, 1996 (Mechler to Cabrem). Shaw had olgecbed to the original 2.02: 'This is 
too ariitiary. Wliy must their belief be well documented? Doesn't this depend on the intended 
use of the software? Doesn't 'safety' also depend on the intended use?" Mechler's response had 
been to repeat v\tot he had said in response to a similar comment concerning 1.14: "Ethics is a 
set of principles or values that guide our judgments." He wanted to guide the judgment of 
software engineers toward using all ^Dpropriate tests, not just some, and to doing a good job of 
documenting their beliefs (and v\tot ttey knew). What tests are appropriate and v\tot is a good 
job of documenting may depend on intended use and is certainly a matter of judgment (among 
otherthings), but v\tot Version 1 said, in effect, is: Don't do without adequate documentation of 
your belief that the product is safe, meets specifications, and has passed all the tests you 
consider appropriate. What objection could there be to that requirement? 

** The principle is "questionable" here (and in interpr^ation of codes of dhics in general) 
but not everyv\tere. It is a standard principle in the criminal law ("No crime without a statute"). 
The principle is questionable in interpreting codes of ethics because a decent person does not try 
to do the minimum she can (without actually doing something wrong). The only way to be 
reasonably sure of not falling below the minimum is to resolve reasonable doubts in favor of the 
more dernanding interpretation, not the less demanding. In ethics, there is something wrong with 
"sailing close to the wind". 

" "[N]o— we put a much more limited definition on this." Comments on Ch^Dter 6 
(September 23, 2003). When I asked Gotterbam what interpretation (and v\tether "this" meant 
"maintaining independent professional judgment", "conflict of interest", or 3.06), I got no 
answer. As the author, I would have lite to know. Plainly, I had somehow failed I would have 
lited to know how. But time has probably closed the door to such knov\dedge. 

^^ The conclusion to draw here is that it would be good to have the knowledge that 
Gotterbam, Miller, and Rogerson claimed but did not have and good too to admit that they did 
not have it 

" The (British) "v\Mlst" suggests that Rogerson wrote this comment Gotterbam, however, 
disagrees: "Simon did have a lot to do with the Code, but his phrase ["outwith"] was just a break 
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from the work. Just as My use of the word whilst— whilst I am in England... .A hunch— but Don 
may be funny here because the OED was given as the Source rather than Webster. I actually 
vaguely recall Duncan [Langford] getting into this issue." Comments on Chapter 6 (September 
23, 2003). The crucial email from Langford, if there was any ("vaguely recall"), seems not to 
have survived. 

^^ See, forexanple, Webster's New Twentieth Century Dictionary of the English Language, 
2d ed. (World Publishing Company: Cleveland, 1960), p. 606; or Thorndike-Barnhart 
Comprehensive Desk Dictionary I (Doubleday & Company: Garden City, New York, 1958), p. 
275. If these references seem too old, going to the current Merriam Webster website yields much 
the same: "to make sure, certain, or safe: GUARANTEE, synonyms ENSURE, INSURE, 
ASSURE, SECURE mean to make a thing or person sure. ENSURE, INSURE, and ASSURE are 
interchangeable in many contexts where they indicate the making certain or inevitable of an 
outcome, but INSURE sometimes stresses the taking of necessary measures beforehand, and 
ASSURE distinctively implies the removal of doubt and suspense from a person's mind. 
SECURE implies action taken to guard against attack or loss." 

*" For exanqie, vMle the OED' s first non-obsolete definition of "assure" is "to mate safe 
against or from (o/obs.) risks; to insure, esp. on mod. usage to assure life: to secure the payment 
if a specified sum in the event of death", the first non-obsolete definition of "ensure" is: "to 
pledge one's credit to (a person); to tell (a person) confidently that (something is true)." 

^° Of course, "condensation" carries this meaning in the US as well; the question is 
v\teher "Europeans" (or, at least, the British) would also understand that the sense intended is 
not pajyment for wrong but pajyment for worlc A visit to the OED reveals that vMle 
"con^Densation" in the sense of salary is an Americanism (2d), the British do use "condensation" 
(2a) to mean, "That v\Mch is given in reconpense, an equivalent rendered, remuneration, 
amends." So, if OED offers a good description of British usage, and even if Europeans still 
learned British English rather than American English, "condensation" should have caused "the 
Europeans" no trouble. 

^' Gotterbarri\Versionl\CMrFULG. I had considered having a similar section eariy in the 
preparation of Version 1 (with the teyword "Supervisors") but had given up because there were 
then too few clauses specifically dealing with supervisiorL Instead, I had treated supervision as 
just one of the activities of "colleagues". Once I had the seven principles, I did not notice that the 
suggestions coming in had swelled the clauses under Principle 6 to the point that division into 
two principles, one concerned with colleagues strictiy so called and one concerned with software 
engineers worldng as supervisors, had become not only possible but desirable. Not then having 
the benefit of Fulghum' s suggestion, I had missed an opportunity to mate the code substantially 
rrore "user-friendly"— as did the rest of SEEPP/E. 

" Version 2 was, of course, in part a response to outside comment, but that is not the same 
as having the new version put to the test of outside comment No code writer knows v\teher a 
provision will pass muster until it has. Every change in a code, even the change of punctuation, is 

192 



a bet that others will see in it what the author does— or, at least not see anything to object to. 
Just as the authors of Version 1 lost many of their bets, so the authors of Version 2 would lose 
many of theirs. 

^^ GotberiDamasks: 'WhylatEintheganie— tlisvvasa(±aftthathadi^^ 
the community it would serve?" Comments on Ch^Dber 6 (September 23, 2003). We have here a 
question about how to interpret the set of facts we have before us (Ch^Dber 6). I say 'late in the 
game" because (technically) "the game" was already in overtime. SEEPP had already missed the 
original deadline for conpletion of the code, and was now woridng beyond the second deadline. 
(That the "game" in fact went on another three years does not change these facts— or the 
perception they should have produced at the time.) My reading of the comments of the 
community the code was to serve had been quite positive, except for those of Failey and Shaw. 
And, on the whole, the criticism of Frailey and Shaw seems to be more a matter of misreading 
the code, or simple ignorance of other codes, than hostility to what the code actually said. What 
constitutes "passing muster" here is a political question, not a factual one. Gotterbam may well 
be right about what was necessary to get the Joint Steering Committee to pass the code, any 
code. But I have no idea how to decide that he was right. And I am pretty sure he doesn't either. 
So, the best I can do here is set out the alternative interpretations. 

^^ Gotterbam thinks this explanation of his conduct in the preceding two years to be 
"nonsense". In particular, he pointed out in comments on an eariier draft of this chcper^ "What 
was going on was not the engineering method— it had nothing to do with large projects. I have 
managed long-terai multi-person projects. The problem was the documentation and review 
method and the way it was being given lip service." Gotterbam Ch^Dber6cmt (October 31, 2004). 
Gotterbam now has no more access to his thinking in late 1994 than I do. We are both involved 
in reconstmcting it from the evidence now available. One problem with his reconstmction is that 
it leaves unexplained v\^ he initially went along with IEEE ^Dproach instead of insisting on the 
ACM ^proach or working out a conpDmise, and v\^ he later changed, exactly v\tot my 
reconstmction does explain (and v\tot it set out to explain). Gotterbam may be right that n^^ 
reconstmction is wrong but, as far as I can tell, the evidence mates n^^ reconstmction the more 
plausible. IEEE procedures got a good deal more than 'lip service" 1994r96. The CEP, 
Operations Guide, and SEEPP organization are "body service" (deeds) rather than 'lip service" 
(mere talk). 
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Gotterbam/94r95 misc/Boston 6-94. 



^ ^ See http://v\tetis.techtargeLcom/definition/0,289893,sid9_gci2141 12,00.html (September 
4, 2004): 'Typically, a skunkworks has a small number of members in order to reduce 
communications overhead A skunkworks is sometimes used to spearhead a product design that 
thereafter will be developed according to the usual process. A skunkworks project may be 
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Chapters: English Spring, Version 2a-2.1 

Major actions are rarely decided by more than four people. If you think a larger meeting 

you're attending is really "hammering out" a decision, you're probably wrong. Either the 

decision was agreed to by a smaller group before the meeting began, or the outcome of 

the larger meeting will be modified by a smaller group later when three or four people get 

together.— "Wolf's Law of Decision- Making"^ 

8.1 A schedule proposed 



Qn Febmary 13, 1997, vMLe still tiying to solve glitches in the "con]des.doc" attachment 
(the annotated Version 2.0 minus Preaniie), Gottedem sent the Joint Steering Committee a 
"Proposed Schedule and Task Force Stmctuie". This was not exactly the schedule for 1997 the 
Committee had requested^ It was more elaborate, a pian with a schedule imbedded in it The 
Schedule began with "general comments" laying out some assurr^Dtions upon v\Mch the schedule 
was based Following the schedule itself was a budget of almost $6000 to cover a website at 
Rogeraon's center (CCSR), two meetings of SEEPFs executive committee, one "meeting with 
Chair of task force [presumably, with the Joint Steering Committee]", and "printing costs, page 
costs, etc., determir^ by the societies irwolved". There was also a post-schedule schedule for 
publication of the code Qanuary 1, 1998-June 1998). 

GotberiDam delivered the Schedule almost exactly a month later than the date Cabrera and 
Frailey had set Either planning the year was much harder than Cabrera and Frailey had 
anticipated or GotteriDam had developed a schedule of a kind Cabrera and Frailey had not 
intended Though Gotteatam had not circulated the Schedule to the listserv, he had circulated it 
to v\tot the Schedule itself identified as a committee to be established, SEEPP's "Executive 
Committee" (EC)— Gotterbam (chair), Miller ("Software Engineering Coordinator"), and 
Rogerson, ("Technical Management Coordinator").^ The Executive Committee was to be part of 
a larger reorganization of SEEPP. The working groups were to be officially abolished.* In their 
place was to be an executive committee and a "panel of experts from Industry, Academe, 
Military, and the Legal Profession": The idea behind this structure was that 

A balanced code will address the engineering, the management and the academic sides of 
software engineering. The structure of the task force reflects that balance. Rather than 
partitioning the leadership along professional association men±)ership lines [the 
organizing principle of the Joint Steering Committee], the executive committee 
represents three areas that need to be represented in the code: a software engineering 
coordinator and a technical management coordinator.^ The previous organization of tte 
SEEPP task force divided the group along lines of ethical issues into separate working 
groups. This was not productive.^ The proposed stmcture of a single panel of experts 
allows individual experts to contribute v\tere their specialty is irwolved The panel 
includes men±)ers from several professional societies including: the ACM, the lEEE-CS, 
the ICCP, the BCS, IDP and the Deutsche Gesdlshaft Fur Informatik. It also includes 
practicing software engineers and ethics advisors for m^or, multinational corporations. 
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practicing software engineers and ethics advisors for major, multinational corporations. 
The panel also has an international representation from places such as Egypt England, 
Germany, and Scotland. 

The point of this part of the Schedule is not obvious. What it asks permission to do had 
already occurred more or less a month before. Since mid-January Gotterbam, Rogerson, and 
Miller had been working together in just the way they would if the Steering Committee declared 
them SEEPP's executive committee. The "panel of experts" seems to be the membership of the 
(enlarged) "Professional Competence Task Force".^ That task force would work no better for 
being declared a "panel of experts". Gotberbam already had the power to call Miller, Rogerson, 
and himself "an Executive Commitiee"; he could call ariyone he recruited to help SEEPP a 
"member of the panel of experts"; he could even officially fire all the working group chairs and 
disband their working groups. Qn January 6, the Steering Committee had expressly given 
Gotberbam the power to do all that and more, "whatever changes in membership or stmctures are 
deemed necessary to acconqiish this task [driving the task force to conqielion]." Plainly, the 
Steering Commitbee was no longer interested in SEEPFs stmcture but in v\tot SEEPP could 
deliver. And, if the Commitbee had interested itself in SEEPF s stmcture (as the Schedule invited 
it to do), it might well have asked what a "software engineering coordinator" (Miller) would 
coordinate that a "technical management coordinator" (Rogerson) could not, or v\^ there was no 
"academic coordinator", "military coordinator", or "inbemational coordinator" as wdl.^ What 
was there to "coordinate"? 

Gotberbam did not need to invite such questions. Indeed, the Schedule's list of 
"ddiberables" seems liMy to have provided the Steering Commitbee with more than it could 
deal with at its February meeting (arid more than it had asked for). Under Febmary 14 (1997) 
were four items the Steering Committee had asked f or^ "a Schedule for conqietion of Code by 
December 1997[;] b. Statement of Code Architecture[;] c. Statement of Relations of Code to 
other Codes; d Second draft of Software Engineering Code of Ethics". To this list, Gottedem 
added (as "Additional Products") two documents the Steering Commitbee had not asked for^ the 
"Statement of Roles of Codes of Ethics" ("Consensus document descrihang the role of codes of 
ethics in professional societies and in particular the roles of a software engineering code of 
ethics; delivered to the chairs of the steering commitbee") and the "Code of Ethics Working 
Papers" ( 'Documentation of all changes and the reasons for these changes made to the first draft 
of the Code"). The "Additional Product" may have been a response to questions Dennis Frailey 
had put in a phone conversation (either on his own or on the instmctions of the Steering 
Committee).^ 

Eariier (Ch^Dter 7) we wondered v\tot point there could be to formalizing Gotterbam's 
"kitchen catanet" as an "executive committee" and the remnant of SEEPP volunteers as a "panel 
of experts". We may now have at least a partial answer. Each of Gottedem's "ddiverdies" 
comes with a brief description of process. For exanqie, under a ("the Schedule"), Gotterbam 
reports: "After review by SEEPP executive committee. Delivered to Chairs of the Steering 
Committee". The same phrasing occurs under b (Statement of Architecture). The phrasing under 
c (Statement of Relations of Code to other Codes) is different: "After review by SEEPP panel of 
experts, delivered as appendix to Code Architecture to Chairs of the steering committee". The 
phrasing under d (the Code of Ethics) implicitly combines these (and perhaps other procedures): 
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"After review by several entities, redrafted and delivered to chairs of steering Committee". The 
small group that we had so far observed work informally and in great haste now sounds like a 
vast organization following its own leisurely procedures. That effect was achieved at the cost of 
a few titles and some careful phrasing (and without any departure from the truth). 

Gotterbam introduced the schedule as an "attempt to meet the Steering Committee's 
request that this project be completed by December 1997." In case the Steering Committee 
missed the point of "attempt", Gotterbam followed with two "general comments". The schedule 
is "very tight" if "completion by Dec 1997 means completion of the code which reflects a 
consensus of those concerned." The schedule is also very tight if the code "ought to [reflect] the 
results of the other task forces" because that would mean that the satisfactory completion of the 
code and statements of practice" is tied to "the progress of the other task forces." 

In fact the schedule is "very tight" even without the if s. The IEEE's standards- approval 
process alone could have taken more than a year. It was a process with its own pace. More 
worrisome than any delay caused by that process was having to wait for the other task forces to 
complete their work before Gotterbam could complete his. So far, the progress of the other two 
task forces had been slower even than SEEPP's. The curricular task force seemed to be waiting 
for the body of knowledge task force to complete work before it did anything. (How could one 
know what to teach if one did not know what was known?)^° Meanv\Mle, after a better start, the 
body of knov\dedge task force was finding, as SEEPP had, that everything took longer than 
expected 

Reorganization at IBM had forced reorganization of the body of knov\dedge task force. 
Douglas had much less time to devote to the body of knov\dedge than she had previously. She 
had recnited Tony Cocchi (conpjter scientist IBM's Watson Research Center) to help her. 
Since Cocchi was active in ACM (and Douglas was active in lEEE-CS), the body of knov^edge 
task force had acquired the canonical dual IEEE- ACM chairs just as SEEPP lost them' ' Because 
Douglas had had less and less time to devote to urq^d work, the body of knov\dedge task force 
had taten much longer than expected to develop its survey. By February 1997, it had a small 
team of experts reviewing the final form. After that there would be a "prototype" survey using 
about fifty volunteers, a review of the results, possible further revision of the survey, and then 
the actual survey. Once the survey was conqiete, the task force would have to develop the body 
of knov\dedge document itself a large undataking. (The Defense Department s Joint Logistics 
Command was funding much of their work.)' ^ Tying SEEPFs work to the progress of the body 
of knov\dedge task force would not mean just a "tight schedule" if conpletion was to be ty 
December 1997; it would mean postponing conqietion by one or more years.' ^ 

Gotterbam seems to have d^gned the Schedule to force the Steering Committee to face 
up to v\tot it vvas asking v\ten it set Decen±)er 1997 as the deadline for conqieting the code. The 
December deadline might force Gotterbam to sacrifice both the consensus- building the IEEE 
standards process worked for and coordination between SEEPP and the other two task forces. As 
if to underline the abandonment of the IEEE process, Gotterbam concluded his general 
comments by noting that the "schedule below reflects techniques we used to achieve consensus 
on the ACM code and make clear to the members of the society that the code did represent that 
consensus." (Note the "we" and the "ACM". Gotterbam is clearly stepping out of the shadow of 
lEEE-CS procedure, setting the weight of his own experience against that of the lEEE-CS.) 
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Gotterbam then laid out the "very tight" schedule. The first date (after February 14) was 
February 28 by which time the Steering Committee was to: 



Return Code v2 with comments to the task force, 
Return comments on any other documents 
Indicate commitment to schedule including 

• booking space in society publications for publication of draft code and 
ballot/survey in September Issues 

• support of WEB site at CCSR 

• support of announcement in society publication of existence of site and invitation 
to comment 

• permission to publicize this schedule to task force 

The next few items will be sufficient to give a sense of just how tight the schedule was (and, 
based on what we have seen till now, how unlikely it was to be followed for long): 

1 March 

Task Force begins addressing steering committee concerns and continues revision 
of the code. 

Establish a web site at Centre for Computing and Social Responsibility on behalf 

of the ACM and lEEE-CS for development and dissemination of the Code. CCSR 

has significant international email lists and it is where I am during the 

development of the code. The web site could be managed by them and then turned 

over to the societies at the end of the project. 
1 April 

Revised Code and working papers to Steering Committee 
15 April 

Place draft copy of Code on web site for general comment. 
1 June 

Completion of Code and associated documents for review by Steering Committee. 

Begin preparation of survey instruments for Code 
15 June 

Revisit documents in light of Steering Committee comments 
30 June 

Finish Revisions 

8.2 Fairweather and Prior 

Though the Schedule seemed to call for an immediate response, the Steering Committee 
did not respond immediately. Indeed, it would not respond for more than a month (and then not 
as Gotterbam had planned). Gotterbam could have waited impatiently, as he had in earlier years. 
Instead, he pushed on, simultaneously writing the Preamble and revising the code. He seldom 
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worked out anything alone. Sometimes he would first talk over his ideas with Rogerson. 
Sometimes, he and Rogerson would sit together at the same computer screen, discussing 
comments as they came in. Once Gotterbam thought he understood what was needed, he would 
prepare a draft and circulate it to Rogerson, Miller, and two others at CCSR whom Gotterbam 
had come to respect, Ben Fairweather and Mary Prior. 

Ben Fairweather had just received a Ph.D. in Moral Philosophy (University of Wales, 
College of Cardiff, 1996). CCSR had hired him because Rogerson thought explaining what 
"social responsibility" meant was in part a philosophical problem. Fairweather had devoted a 
chapter of his dissertation to a discussion of codes of business ethics.^^ When Gotbertem arrived 
in January 1997, Fairweather was working on a p^:er concerned with codes of conpjter ethics 
("Why an Inconplete Code is Worse than None at AH").' ^ He had been looking at codes linted 
to CCSR' s website. He was therefore ready to look at another code— and liMy to have strong 
ideas about v\tot a code should contairL Fairweather knew little about sofbA/are engineering 
(though he had started college in conqxrter science, switching to philosophy after the first year). 
One day injanuary, Gotterbam gave lim a draft of the code and asted for comment Fairweather 
did as asted and was from then on part of the drafting process."" 

Lite marry in corrpiter science, Mary Prior began her career doing something quite 
different Having received a B.A. in English from the University of Lancaster (1975), she 
worted for a decade as a librarian As the libraries in v\Mch she worted became more and more 
dependent on corrpjters, she had become more and more involved in information systems. 
Eventually, she decided she should know more about corrpjter science than she could pck up on 
her own She returned to school, taking a Master of Science in Conpjter Science from the 
University of Aston inl988. By the time she received her degree, she was no longer interested in 
working in libraries. She wanted to teach. DeMontfort offered her a university lectureship in the 
School of Conpjting. She accepted By 1997, she was teaching Systems Analysis and Design, 
Data Modelling and Database Design, and Conq^arative Systems Development Methodologies. 
Even so. Prior did not consider herself a software engineen 

I work on business ^plications of software. My concern is the use of corrpjters in 
business organizations. Engineers bdld software. I analyze the needs of business to 
deteraine v\tot kinds of software they need I might write specifications for software, but 
I would not bdld the software. ' ' 

Prior first heard about SEEPP from Gotterbam v\ten he arrived in January but she had been 
thinking about codes of ethics for at least two years. AU she needed to participate was a personal 
invitation'^ 

Though Fairweather and Prior were both at DeMontfort Gotterbam did not work with 
them in the same way. He communicated with Prior— v\tose office was just one floor above 
his— almost entirely by email but with Fairweather in a variety of ways. Fairweather lited to 
have a p^:er draft of the code to read, and time to think before responding. As Fairweather 
recalls, he gave his comments orally at "frequent face-to-face meetings with Don and Simon 
[Rogerson]," but he also responded by email directly to Gotterbam— sometimes in response to 
personal emails from him but sometimes in response to emails sent to the SEEPP listserv.' ^ As 
Gotterbam recalls it more of Fairweather' s comments were in writing and email than oral.^ ° 
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Gotterbam had then independently developed at DeMontfort a drafting process 
remarkably similar to the one I had at IIT. At the core were frequent meetings among three 
people (Bumstein, Weil, and me at IIT, and Fairweather, Gotterbam, and Rogerson at 
DeMontfort). Beyond this core were a few others, most quite distant, emailing contributions (El- 
Kadi, Mechler, and Norman for IIT, and Langford, Miller, and Prior for DeMontfort)?^ 
Gotlie±)am would present a draft receive comments, revise as he thought wananbed, and then 
present a new draft (with all changes indicated), asking for responses to the changes. Ideally, he 
would have continued that pnxess until there were no objections (as I had done), but I, who had 
no real deadline, had begun drafting Version 1 inMay 1996, submitting the final draft in October 
(almost six months later); Gotbedem' s Schedule allowed about half as long for an undertaking of 
equal scale (with more or less hard deadlines inposed by the publication schedule of various 
journals). We should not then, be surprised if his work shows signs of haste (such as a difference 
in terannology under different rules). What is surprising is how fast Gotbedem sometimes 
worted For exanple, the day before Gotbedem sent the listserv the Preamble, Miller emailed 
his comments (two-and-half pages single- spaced). Most of the changes Miller suggests are small, 
but some are not Some of the suggestions were incorporated inbo the draft sent out the next 

Though Miller was in the US during most of early 1997, corresponding with Gotbedem 
largely ty email, he had a part in the process at leasb as large as Fairweather and Prior. He 
always corresponded with Gotbedem directly (and privately). Not all the correspondence has 
survived, but v\tot has survived shows Gotterbam and Miller often thinking together about 
particular questions of drafting. For exanqie, eariy on February 5, Gotbedem sent Miller a rough 
draft of an eariy version of 2.0 (but v\Mch he called "Vl.a")— with questions inserted here and 
there throughout the document The email began, "Simon and I had a productive morning. What 
do you think of the following: 1 . Stmcture. Code starts with a preamble— yet to be worted out— 
probably v\ten finish[ed] with rest of code." Miller responded to this email the same day, 
inserting a response after each question For exanqie, in response to this first question. Miller 
wrote, "As I wrote before, I lite the idea of an extensive preamble."^ ^ 

Similar emails survive for Febmary 9, Febmary 10, and March 17. The March 17 email 
mates a number of suggestions for the Preamble that Gotterbam was then rushing to conqiete. 
Among Miller^ s suggestions were replacing "enormous" (in the first paragr^ii) with 
"significant' because "'enormous' seems a hat dramatic"; deleting "all" from "all three levels" in 
the third paragr^ii; replacing "deeper^' with "deepest' in the same paragr^ii ("third and deeper 
level"); and rewriting the sentences in this paragr^ii to put than in tte active voice. After 
discussing them with Rogerson, GotteriDam followed most but not all. Miller' s suggestions. 

8.3 Preamble trouble 

On March 18, 1997, less than two weeks before the revised code was to go to the 
Steering Committee, GotteriDam emailed the listserv the promised preamble (Preamble v 2.0). 
What was a single paragr^±i in Version 1 had become eight paragr^±is. The Introduction (name 
changed to "Preamble") was now a littie essay, a page and a half long, single spaced The first 
paragraph reseniies the original. The first sentence is identical except for the addition of 
"education" and "social affairs" to the list of roles (previously "commerce, industry, government 
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medicine, entertainment and ordinary life). The second sentence replaces the original (partial) 
definition of "software engineer" ("those who design, develop, and test software") with another 
("[those] who contribute, by direct participation or by teaching,^'^ to the design and development 
of sofbA^ie systems").^ ^ The chief change in the third sentence is the addition of "must". Instead 
of descritang sofbA^aie engineers as people v\to "commit themselves to making the design, 
development, and testing of software a distinct, beneficial, and respected profession", it now 
demanded: "[they] must commit themselves to making the design and development of software a 
distinct, iDer^dal, and respected profession" Apparently, one can l^e a software engineer 
without such a commitment (the "must" of comniand always inqiying the alternative as a 
possLtality) } ^ The fourth sentence is exactly the same in ]x)th versions ( 'In accordance with that 
commitment software engineers shall adhere to the following code of ethics") .^ ' But the last two 
sentences of Version 1, the ones that Frailey and Shaw had criticized ^ are gone, their place 
taten ty seven paragr^±is each about the same length as the first 

Lite their counterpart in the ACM code, these seven paragr^ahs are neither numbered 
nor titled, making reference to them av\A?ward The absence of titles ("teywords") also mates it 
hard to see the Preamble's stiucture and hard to find v\tot is there (or, at least harder than need 
be). The casual user may not even realize that ariything useful waits in what (conqaared to the 
numbered, titied, and minutely divided body of tte code) must ^Dpear an undigested sprav\d of 
prose. Yet, there is much to ponder in these seven paragr^±is. The first three of the new 
paragr^iis— the Preamble's second, third, and fourth^togettier explain the stmcture of the 
code. The second (of the eight) explains the relation of teywords to principles. The third 
paragraph relates the principles to Gotterbam's "three levels of ethical obligation" (human, 
professional, and profession-specific). The fourth paragr^h explains the content of the specific 
clauses, introducing v\tot seems to be another three-level distinction (aspre, expect and 
demand), attenuating to connect it to the other. The attenq* does not seem successful. For 
exarrqie, the following is offered as an exarrqie of 'Tevd Qrie": "Aspre (to be human)". Since 
those addressed (software engineers) are human, it is hard to see what (literally) there is to 
aspire to.^^ The intended meaning seems to be that software engineers should aspre to do v\tot 
humans should do (or should aspre to treat themselves neither as having more rights nor fewer 
duties than humans as such have). That aspration has troubles of its own The standards that 
^Dply to humans as such (that is, morality) include marry (such as 'T)on't kill", "Don't lie", and 
"Don't steal") that seem better categorized as 'Tevd Three" ("demand"). Mere aspration is not 
the right attitude to tate toward basic moral rules. One conclusion to draw from these three 
paragr^±is is that there is something fundamentally wrong with Gottedem's theory of code 
stmcture.^" 

The next four paragr^±is offer advice on how to use the code. The first of these— the 
fifth of the dght— warns that the code is "not intended to be all inclusive nor is it intended that 
its individual parts should be used in isolation to justify errors of omission or commission"; it is 
also "not exhaustive" and not intended to be "read as separating the acceptable from the 
unacceptable in professional conduct in all practical situations." The code is not a "sinple ethical 
algorithm". The fifth paragr^h having explained v\tot the code is not the sixth explains v\tot 
the code is, "[an atterrq* to] influence you to consider broadly v\to is affected by your work; to 
examine if we are treating other human beings with due respect; . . . .and to consider if your acts 
would be considered worth[y] of the ideal software engineer." Software engineers should 
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interpret the code in such a way that they can answer yes to the question, "[Have I acted] in a 
manner likely to be judged as the most ethical way to act in circumstances by informed, 
respected, and experienced peers in possession of all the facts"? The seventh and eighth 
paragraphs explain the utility of the code. The code "provides support for the software engineer 
who needs to take positive action by documenting the ethical stance of the profession". It also 
has an educational use, "stating what is required of anyone wishing to join or continue in the 
software engineering community". In sum, "[because] it expresses the consensus of the 
profession on ethical issues[,] it can be used as a guide to decision making and as means to 
educate both the public and aspiring professionals about the professional obligations of software 
engineers." 

Gotterbam's covering letter announced to SEEPP's listserv that version 2 (without the 
Preamble) went to the Steering Committee "last month" (presumably, on February 14) along 
with the schedule. He did not say what the Steering Committee did with either the schedule or 
the code, but noted that the schedule included "several internal review cycles" before preliminary 
distribution for wider comment. After revision in response to the preliminary comments, it would 
be distributed through "the major publications of each society for review [JULY issues] and 
balloting on each code element." It is therefore "important to get your comments on both the 
code and the preamble to me as quickly as possible." 

This call for comments on the Preamble had an immediate effect. Prinzivalli (the 
engineer from California who commented on Version 1) responded the same day, March 18, 
using the listserv. He had three comments (after thanking Gotterbam for his "leadership and 
stewardship of this very important software engineering statement on ethics and 
professionalism"). First, he suggested changing the word order of the last sentence in the fifth 
paragraph, moving "given the circumstances" from the end of the sentence to the beginning 
("Given the circumstances, these situations require the software engineer to use ethical judgment 
and to act in a manner which is most consistent with the code of ethics"). Second, he wondered 
about the sixth paragraph's use of "ideal software engineer". Third, Prinzivalli proposed 
inserting "all" before "software engineers" in the last sentence of the eighth paragraph 
("...educate the public and aspiring professionals about the professional obligation of all 
software engineers"). 

The only other comments Gotterbam received seem to be from Fairweather. Fairweather 
had a dozen suggestions. Some seem intended to add precision (for example, adding "and to 
influence and enable others to do good or cause harm" after "and to cause harm" in the first 
paragraph. Some were more philosophical (such as the substitution of "rationality" for 
"humanity" in the third paragraph). And some were purely editorial (for example, also in the 
third paragraph, changing "for those effected [sic] by their work" to "for those who may be 
vulnerable to the effects of their work"). Fairweather' s comments survived only in a paper copy 
in Gotterbam's files. Beside each of Fairweather' s suggestions is Gotterbam's check, X, or 
question mark. Gotterbam believes he made these marks after discussing the comments with 
Rogerson and Fairweather. He may also have received comments on Fairweather' s suggestions 
from Miller.^^ 

8.4 The problem of silence 
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Not only did the world in general (apart from Prinzivalli) fail to respond to Gotterbam's 
March 18 email, even the Steering Committee continued its worrisome silence, a silence so 
worrisome that Gotterbam emailed the Steering Committee (and the task force listserv) a 
"Project Management Status Report" three weeks later (April 7) that began, "We need your 
response."^^ Gotbertem seems to have hit upon the idea of a status report only a short time before 
seeding it ouL^ ^ Indeed, there exists in Gotterbam' s files an email thdt begins: 

DEAR EXECUTIVE COMMTTTEE: 

This is v\tere you eam your money !!!! 

I need an hour of your time now. Situation is - No Response from the Steering 

Commitbee about permission to circulate code for review. Publication deadlines will 

cause delays until September unless I get them to move before the end of THIS WEEK. 

Though undated, this letter^ s reference to the need for the Steering Committee to "move" befo re 
the end of "this week" means that it probably could not have been sent before Sunday, April 6, 
1997 (the first day of the week), and since Gotterbam actually emailed the Status Report late on 
Monday, April 7, the letter must have been sent before then. Later in the letter, Gotterbam refers 
to a few things "we need to do... in the NEXT HOUR." Though it sounds like humorous 
exaggeration, it was, according to Gotterbam, the literal truth and, more surprising, he felt sure 
that, if the two other members of the Executive Committee received the email in time, they 
would read it and promptly do what he asked.^* 

Gotterbam was asldng a great deal of them (Rogerson and Miller). First, he was asking 
them to review the report itself, noting "sometimes I have a tendency to step on (and crush) 
toes." Second, he asted the executive committee to read and "word smith" the "introduction to 
the proposed article (two short paragr^±is explaining v\tot the code was and v\tot those reading 
it in a publication should do with it). Tliird, Gotterbam noted that the code "is not QUITE ready 
to show the steering committee". There were, first of all, changes (indicated in c^tal letters) 
made in response to comments on "draft 2" (presumably, version 2a). The Executive Committee 
should "comment" but "sinqiy Yea or Nea [sic] will do." There is also the question of v\tere to 
put Section N— and v\tot N should say. Last, "we still need 3.08 plus principles— v\ten to blow 
the v\Mstle, and social clauses." 

A survey of the document ^Dpended reveals marry more issues to reolve "in an hour^'. 
For exanqie, stould clause 1.07 ("Ensure realistic estimates of cost, scheduling, personnel, and 
outcome on ariy project on v\Mch they worlc or propose to worlc") be amended by adding "and 
realistic estimates of the chances of not meeting those estimates"? Should "worlc to" replace 
"aspre" in 1.10 and 1.14? Should the following clause be added under Principle 2: "endeavour 
to produce software that respects the equality of all humanity: in particular recognize that not all 
people speak English as a first language, that poorly designed software can prevent disabled 
people from doing things they could otherwise, and that high-technology products tends to tate 
we^ from the poor^'? Should the following clause be inserted under Principle 3: "Be aware that 
all technical judgments inpact other human beings. Technical judgments Iwe stateholders other 
than enqioyers, clients, and users"? In an hour or so, all these issues were settled and Gotterbam 
emailed the Steering Committee his Project Status Report 
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The Report begins where the Schedule left off. After reminding the Steering Committee 
of what he had sent them on February 13, Gotterbam warned that for the "SEEPP Task Force to 
move forward[J we need from you, 1) your comments on the code, 2) approval for the 
establishment of the web site, [and] 3) approval to distribute the code for comment using society 
journals." Then, as if to provoke some comment on the code, Gotterbam wrote, "We have not 
received any comments on the code from you, so can we presume that we are getting closer to 
the mark with the code and that the explanations of the changes were satisfactory?" There 
follows two longer paragraphs, one describing the present state of plans to post the code on the 
IEEE and ACM web sites, noting that the Steering Committee had not yet provided the names of 
contacts at IEEE or ACM that Gotterbam had asked for. The other paragraph made a similar 
point about publications. The deadline for one cmcial publication (ACM's SIGCAS) had already 
passed, but "the editor is willing to accept the document if I can get it in by the end of the week." 
The deadline for other publications was getting close. Unless Gotterbam got the Steering 
Committee's permission to publish the draft code soon, he would miss the July deadline, pushing 
publication of the code back to September. Gotterbam said nothing about budget. He had given 
up on that. It would have been "a distraction". His goal now was to get the draft published. Once 
published, it would become much harder to stop.^^ 

In case the Steering Commitlee did not appreciate the impoA of all these details, 
Gotle±iam mates the point again, taking a whole paragraph that begins, "The project is at a 
stand still. The time specifically dedicated to this project is being used waiting for approval to 
move forward" The paragraph flew its red flags in a way not liMy to be missed— in part by 
making the project sound in worse sh^:e than it was (though poiti^ng accurately the dangers 
already in view). The project was not "at a stand still" yet; the proof that it was still moving 
forward was just below Gotterbam's "Report": the "Proposed Product for Publication", v 2.0a of 
the code. The "a" indicated that the code had been amended since Version 2.0 in ways 
representing a continuation of work rather that the sort of corrections that "2.1" would normally 
have signaled. The amendments— (almost always) indicated by capital letters— tell us 
something about how Gotterbam (consulting with Miller and Rogerson) worked with the 
suggestions others offered. For example, we know that Prinzivalli made three suggestions 
conceming the Preamble. While nothing is done about the first (moving "given the situation" to 
the front of its sentence), Gotterbam simply accepted the third (inserting "all" before "software 
engineers"). His response to Prinzivalli' s second comment is more complicated. He did not 
abandon the appeal to virtue ethics implicit in "the ideal software engineer" (as Prinzivalli' s 
comment seemed to have suggested) but tried to clarify the point of the appeal. The cmcial 
passage in the Preamble's sixth paragraph now read: "consider if your acts would be considered 
worthy of the ideal PROFESSIONAL WORKING AS A software engineer." Gotterbam was no 
mere "scribe" .^^ 

Many similar changes, large and small, are scattered through Version 2.0a. Among the 
most inpDrtant is a series suggesting that Gotterbam thought the process of weaterdng the code 
(making it "more asprational") may have gone too far. The first hint of this is in the Preamble. 
The last sentence of the sixth par^r^±i now read: "Since this code represents a consensus of 
those engaged in the profession[,] one should TAKE INTO ACCOUNT WHAT IS liMy to be 
judged as the most ethical way to act in the circumstances by informed, respected, and 
experienced peers in possession of all the facts AND ONLY DEPART FROM SUCH A 
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COURSE FOR PROFOUND REASONS, BACKED WITH CAREFUL JUDGEMENT".^^ 
Though not an algorithm, the code is to be more than a "guideline". Software engineers are not 
free to interpret it siny way they fed is right They are to tate account of v\tot "the profession" 
would do— operationalized as the probable judgment of one's "informed, respected, and 
experienced peers". To depart from the code so interpreted, a software engineer must have 
"profound reasons", nothing less.^^ There will, thea seldom be reason to depart from the code 
(properiy interpreted). In this respect at least. Version 2.0a lays down rules strictly so called 
(though rules for v\Mch there may be a few exceptions). Though the Preamble' s fifth paragraph 
contains new language that may seem designed to weaten the code— the insertion in its last 
sentence of "sprit of the" between "consistent with the" and "code"—, it is in fact part of a 
larger revision having the opposite effect The last sentence of the sixth paragraph provides an 
interpretation of "in the sprit of the code" (indeed, a relatively demanding principle for 
interpreting the code). What is in the sprit of the code is generally acting as the most informed, 
respected, and experienced men±)ens of the profession would intapret the code, departing from 
that standard only for profound reasons. 

Among other changes in Version 2.0a that mate it more demanding than Version 2.0, 
some are small changes. For exanqie, clause 1.04 now read, "Ensure proper AND 
ACHIEVABLE goals and otgectives for smy project on v\Mch they work" It is no longer enough 
to ensure that the goals are proper (that is, not contrary to technical, legal, or other relevant 
standards); the goals must also be practical. Clause 1.07 was revised to require a "risk 
assessment of these estimates [of cost scheduling, personnel, and outcome]". The revision of 
2.01 is a lit more subtie. In Version 2.0, 2.01 required software engineers to "[disclose] to 
^Dpropriate persons or authorities einy actual or potential danger that the software or related 
docurrients on v\Mch they worted . .posed" If they were wrong about a danger, their conduct 
would be urgustified (ttough excusable). Under Version 2.0a, software engineers would be 
justified in "blowing the v\Mstie" if they merely "reasonably believe" that such a danger exists. 

Other changes are larger, the insertion of a whole new clause (or something very close to 
that). So, for example, a new 1.12 had been inserted ("Delete, whenever appropriate, outdated or 
flawed data")— with the clauses following renumbered accordingly.^^ A new 2.05 (under Public) 
required software engineers to "[endeavor] to produce software that respects diversity". The 
clause then went on (in a way violating the code' s general format) to explain the clause in a full 
sentence: 'Issues of language, different alilities, physical access, rrental access, economic 
advantage, and allocation of resources should all be considered" Principle 5 (formeriy N) now 
read, "A software engineer in a management or leadership capacity SHALL ACT FAIRLY AND 
SHALL ENABLE AND ENCOURAGE THOSE WHO THEY LEAD TO MEET THEIR OWN 
AND COLLECTIVE OBUGATIONS, INCLUDING THOSE UNDER THIS CODE. IN 
PARTICULAR, THOSE SOFTWARE ENGINEERS IN LEADERSHIP ROLES SHALL AS 
APPROPRIATE". The old Principle 5 had become Principle 6 (with subsequent principles 
renumbered accordingly) . 

Version 2.0a was still plainly a work in progress. So, for exanqie, the switoh from 
"assure" to "ensure" remained inconplete. Principle 1 itself retained "assure", though "assure" 
no longer speared in any of the clauses under it The first two of the nine clauses of Principle 5 
also retained "assure" (as they did v\ten they had an N in front of them in Version 2.0). 5.01 read 
"Assure that enqioyees are informed of standards before being held to them" and 5.02 "Assure 
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employees know the employer's policies and procedures for protecting passwords, files, and 
other confidential information." "Assure" also appeared in 4.02 ("Assure that any document 
upon which they rely has been approved by someone authorized to approve it"). Since these 
clauses were the same as in the previous version, we might suppose that they remained the same 
because Gotterbam had not looked closely at them, his attention focused on the clauses he was 
rewriting. But that explanation will not do. Clause 6.02 retained "assure", though revised to read: 
"Assure that clients, employers, and supervisors know of the software engineers commitment to 
this code of ethics, AND THEIR OWN RESPONSIBILITIES UNDER IT."^° 

One change in the code, one that is nov\tei:e noted and may have been inadvertent, is in 
the name. Version 1 was titled "The Code of Ethics for SofbA^are Engineens". The point of using 
the noun "Engineers" was to suggest that the code ^plied to the men±)ei:s of a profession 
(software engineers), not just to anyone performing a certain function (software engineering). 
Version 2a (April 17, 1997) is titled "Software Engineering Code of Ethics" (changing tiie 
emphasis to function). The only evidence that the change in title was inadvertent is that the short 
essay introducing the code refers to the code by its former name (as if nothing had changed).*' 
Could this (significant) change of title really have h^Dpened by accident? Peih^]s. (I did not 
noticee the change until I began writing this book.) 

Version 2.0a contained one more innovation worth comment Unlite preceding versions 
(but lite the ACM' s code), it ended with a (still rough) statement of credit 

This Code was developed by the ACM/IEEE-CS joint task force on Software 
Engineering Ethics and Professional Practices Task Force: Donald Gotterbam, Chair) 
Keith Miller and Simon Rogerson, Executive Committee; Members: Peter Bames, Steve 
Barber, esq., C.S. Burstein, Amr El-Kadi, BenFairweather, Milton Fulghum, N. Jayaram, 
Tomjewett, M^. A. KankD, Ernie Kallman, Duncan Langford, Joyce Currie Litile, Ed 
Mechler, Manriy Norman, Douglas Phillips, Peter Prinzivalli, Mary Prior, Patrick 
Sullivan, John Wectert S. Weisband and Laurie Werth. 

This statement of credit is interesting both for v\to is credited and v\to is not (or, rather, v\to is 
listed as on the task force). "C.S. Bumstein" seems to be IIT's Ilene Bumstein (the "C.S." being 
her department's initials).*^ She is the only one of IIT's three participants to be listed She is, 
however, not the only one of SEEPP/E's members to be listed El-Kadi, Jayaram, Mechler, 
Norman, and Sullivan are all there. So, of the IIT-SEEPP/E contingent orrly Weil and I are 
missing (though the third, Bumstein, is wearing false initials). All men±)ers of the original 
SEEPP task force but two are there Barber, Littie, Miller (though for other reasons), Sullivan, 
Weisband, and Werth. Only Medford and MacFariand are not We know v\^ Medford is not 
but v\tot about MacFariand? Was he omitted by oversight or because he had resigned? 
Resignation does not seem to explain MacFariand' s omission Barber had resigned (October 
1995) without ever working on the code (though he had done much work on other things eariier). 
Yet he IS listed. 

Of the remainder of the list at least two (Fairweather and Prior) had commented on the 
code but never asked to be on the task force. Four others (Fulghum, Kanko, Langford, and 
Prinzivalli) had both joined the task force in response to the Call and had commented on one 
draft or another. Jewett, Kallman, and Phillips had joined the task force in response to the Call 
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but had not commented on the code. Of the several dozen who had joined the task force in its 
first year and did nothingafterward, they are the only three listed.'^^ Peter Barnes (British) seems 
neitto to have joined the task force at any time nor to have had anything to do with the code. 
His presence on the list is a niysteiy (not least to him).** John Wectert (an Australian), wbom 
Gotteatam had recently seen at a conference, had (again) expressed an interest in the project but 
had not yet done anything. *^ Missing from the list— beside Weil and me— is tte Gennan 
"expert" (or, indeed, aiiyone from the Continent) that Gotteibam had claimed for the task force 
("tte panel of experts") less than two months before. 

Gottertiam may have had tte same purposes in view in this list as tte ACM had v\ten it 
credited both ttosev\tohdped draft tte code aid ttosev\to, after tte drafting was done, lent tte 
proposed code their auttority. Gotteibam was certainly willing to credit everyone v\to had 
helped in any way with tte drafting. He had omitted Weil and me only because he ttought that, 
as researchers studying tte process, we did not want to have attention directed to our part in tte 
process. When (marry months later) we indicated otherwise, te immediately added our names to 
tte list. *'' What seems plain from tte list is that Gotterbam had not yet worted out wtet. steuld 
count as a good reason (other than hdpng with tte drafting) to te on tte list. Listing men±)ers of 
tte task force worted only if ttose listed were still men±)ers of tte task force and only if 
everyone v\to contributed was a member. But some (lite Barber) were no longer members and 
others (lite Prior) never were. Listing only ttose v\to actually contributed something to tte code 
would have meant leaving out marry v\to, ttough not auttors of tte code strictly speaking, could 
lend auttority crucial to winning tte code's adoption (or had aided SEEPFs work in other 
ways). We may, then, expect this statement of credit to go through at least as marry revisions as 
tte code— for much tte same reason (tte difficulty of finding tte right balance between principle 
and politics). 

8.5 Tte Steering Committee responds 

A day after Gotterbam sent out tte "Status Report" (with Version 2.0a ^Dpended), te 
received an email from Frailey (tte Steering Committee's vice chair) announcing tte 
Committee's double response. Tte Steering Committee had met that day (April 8) and agreed to 
auttorize publication of tte code "in newsletters, web pages, and other non-archival 
publications. . .to solicit irpjts from software engineers". There were, towever, two "provisos": 
First, there was to te a "cover memo" from tte Steering Committee to "acconpariy all copes of 
tte draft" Stuart Fddman, an ACM-appointed men±)er of tte Steering Committee, was to "get 
with you on tte cover memo, v\Mch tte Committee must ^Dprove". Tte intent of tte cover 
memo is to mate clear v\tot "it [tte draft] is and is not" Secord, tte Steering Committee wanted 
its "cover memo" to ^Dpear along with tte code on toth tte IEEE and ACM web pages 
(preferably on tte IEEE web page with a link to ACM). Barbacd "will get with [Gotterbam] on 
tte webmaster."*' 

That was tte Committee's first response to Gotterbam's Status Report It was, in a back- 
handed way, good news. Tte Steering Committee had broten its long silence and, in effect 
accepted the schedule Gotterbam had sent them in Febmary and tried to teep to ever since. 
Gotterbam' s "Status Report' had worl^d Tte Steering Committee had acted with unbelievable 
speed (meeting, it turned out ty conference call) .* ^ Frailey' s email itself seemed to stow that tte 
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Committee understood the need for speed (or, at least feared its message might be lost). The 
email began, "Don, please acknowledge receipt of this." Unfortunately, that was the only 
evidence that the Committee appreciated Gotterbam's worries. The Committee had not done 
what Gotterbam had asked (comment on the code, approve establishing a web site, and help with 
getting the code published in appropriate journals). Instead, it had done precisely what he had 
asked them not to do; it had introduced "small delays" (the time necessary to get their approval 
of the cover memo) that could "cause the project to drag out". 

The request for the cover memo was the Committee's surprising first response to the 
Status Report. Even more surprising was the second. The Committee wanted (Frailey said) to 
"issue certificates of appreciation to those who made significant contributions to either draft of 
the code." The certificates were to be distributed during the awards ceremony of the (lEEE- 
ACM-sponsored) 1997 International Conference on Software Engineering (ICSE '97)— to be 
held in May. Gotterbam was to prepare the list and send it to Elliot Chikofsky (an lEEE-CS 
appointed member of the Committee)— with a copy to everyone else. Gotterbam was to include 
himself on the list of awardees "of course.:-)" On the surface, the idea of honoring those 
contributing to the code seemed a good idea. They deserved some honor for all their unpaid 
work. But the timing was odd. ICSE '97 was just over a month away. Work on the code would 
not be over by then. The code would have to go through at least one more revision (two if the 
February schedule was to be followed). And, of course, nothing guaranteed that work on the 
code would end in success, that the code would be adopted. The awards seemed premature. Was 
there a hidden message? Was the message, "Sorry about the cover memo"? Or, "Keep up the 
good work"? Or just, "Look at what we're doing"? Whatever the message, Gotterbam accepted 
the award from Barbacci a few weeks later at a dinner held as part of an IEEE function in 
Pittsburgh.'^^ Miller received his in the mail a few weeks later.^° Rogeison received his the 
following year.^ ' No one else v\to had contributed to "either draft" received ariy award for their 
work 

Frailey sent his email on Tuesday, April 8, promising to send the (un^Dproved) minutes 
of the meeting later (and did as promised before the end of the working day). Gotterbam does not 
seem to have read either email until late April 9 (between 10:00 and 11:00 in the evening). He 
was at The Hague on Tuesday and Wednesday (along with Rogerson) meeting with the Dutch 
Office of Technology Assessment and making preliminary arrangements for ETHICOMP 98 
conference at Erasmus University.^ ^ 

Gotterbam read both emails v\ten he returned to Leicester Wednesday evening, but 
waited till the next day (April 10) to respond There was much to think about— not least those 
listed as attending the meeting: Cabrera was there only briefly and, ^Dparently, only read "some 
thoughts" of the absent Zweben (ex officio in virtue of being ACM President) had asked him to 
give the Committee. Boehm and Shaw (both ACM-appointed members) were also absent. Even 
meeting by conference call, the Committee had in fact had only six of its ten members present 
for most of the meeting (only two of them ACM appointees). Was the Committee, or at least the 
ACM-appointees, losing interest? In spite of the low attendance at the meeting, the Committee 
agreed to meet "regularly" by conference call, "perhaps every three weeks" (at a time "to be 
agreed on by committee members"). Had the Steering Committee failed to respond to Gotterbam 
over the last two months because it had not been able to arrange a face-to-face meeting? There 
was evidence of that. Though apparently called in response to Gotterbam's Status Report, a third 
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of the meeting (or at least a third of the minutes) was devoted to the "Survey for Body of 
Knowledge". The body of knowledge task force had completed its survey (or, rather, a pilot) and 
was to have certificates just as the SEEPP task force was. "All" members of the Committee were 
to "respond to the call for dialog [concerning the survey] with well- conceived analysis and 
recommendations— Deadline will be April 30, 1997." There was a similar "action" for the code 
of ethics. "All" were to provide "feedback to Don Gotterbam on the draft code by no later than 
May 31." There was nothing about the curriculum task force.^^ Was it still waiting for the body 
of knov\dedge task force to conqiete its work? 

Just before midnight on Wednesday (April 9), Gotterbam opened two emails from Pder 
Knote, one entitled "A sanqie exerdse with your draft SE code" sand the other, 'TViore from the 
Far North Ethics Committee." Knote taught conpjter science at the University of Alaska- 
Fairbanks. Gotterbam had seen him often at the annual Conference on Software Engineering 
Educatioa^* Though Knote had not participated in SEEPP online since his original expression 
of interest (Noven±)er 8, 1994), his address had migrated to the listserv; he had been reoling the 
email; and the status report had at last given him a way to participate. Knoke had (according to 
the first email) given his class of fourteen seniors in conpier science "your draft code" (which 
version he did not say), asking them to ^Dply it to "selected paits of 'Killer Robot . . . [and more] 
recently. . .to Bill Gates."" Below was "a sample" of the response, one paper about Bill Gates 
who "[seems] to be widely disliked up here (not by me of course)." Knoke was grateful to 
Gotterbam for "helping me by sending the draft code" and would "now like to give you the 
feedback you asked for." How would Gotterbam like to be fed? "For example, will bits and 
pieces (like this one) be helpful, or would you prefer that I provide some kind of summarizing 
paper?" The first option "gets quick data"; the second, would take longer. The second email was 
another student essay. We do not know what, if anything, Gotterbam wrote in response. We do 
know he did not add Knoke's name to the list of those contributing to the code (perhaps because 
only his students actually made suggestions). 

8.6 Pressing forward 

Thursday (April 10), Gotterbam worked on the "cover memo" the Steering Committee 
had requested. After consulting with Miller and Rogerson, he decided to expand the existing 
two-paragraph introduction instead of adding another document. By Friday, he was ready to 
contact Feldman (who had not yet contacted him). The email, eight pages single- spaced, 
contained: a covering letter (about half a page); a brief essay entitled "Software Engineering 
Ethics Code", by "Don Gotterbam, Keith Miller, and Simon Rogerson" (about a page long); the 
"Draft Software Engineering Code of Ethics, Version 2.1 April 1997" (the next seven pages 
including the "credits"); and last, contact information (including Gotterbam's Tennessee mailing 
address). The tone of Gotterbam's covering letter is cool but informal. There are no pleasantries. 
It begins abmptly after the salutation ("Stu"): "Three items. First the 'cover memo' ." Gotterbam 
then admits that he is "not sure what the steering committee had in mind" but thinks "a cohesive 
document with an introduction and the code [like the one below] would work better." What 
follows that is an explanation of that "cohesive document": 
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I wrote an article about the entire project in a book[J "The Responsible Software 
Engineer". The article was based on note[s] supplied by the steering committee when 
Mario was chair and the article was approved by the steering committee. I have 
abstracted from that article a statement of the background for my task force. This 
abstract is the first two paragraphs of the document below. This is followed by a 
paragraph stating that this is a draft code and soliciting comments. Then comes the code 
followed by contact information. It would help if we could say where at each web site 
this will be found. Abstracting from an already published document should make the 
committee approval process easier. 

Gotterbam did not know why Feldman, a high-ranking computer scientist at Bellcore, was asked 
to work out the cover memo with him. ^^ The most liMy reason was that Fddman had suggested 
a cover memo to acconpariy the code. Why he should have done that was not clear, but v\^ the 
Steering Committee approved the suggestion was: the Committee was unwilling to do ariything 
that might seem to endorse Version 2.1. 

The second "item" in Gotterbam' s email seems designed to get Fddman to respjnd 
quickly. Gotterbam admits to not having "heard back from SIGSOFT yet, but the editor of 
SIGCAS [the quartedy publication of ACM' s Special Interest Group on Conpjters and Sodety, 
Tom Jewett,] has alr^dy ddayed two weeks and was told ty the publisher that the final copy 
must be fed exed ty Monday afternoon [April 14]." ^ ' If Gotterbam did not meet that deadline, 
the draft could not ^Dpear in that uip^rtant journal "until September", three months later. If 
Fddman did not ^Dprove Gotterbam' s essay quickly, or propose some acceptable substitute, he 
would be responsible for ddaying the code project several months. 

The tMrd "item" suggests that Gotteibam thought that the Steering Committee had a low 
opinion of his alility to teep the various versions straight Why dse would the Committee be at 
such pains to assure that he put the same version of the code in every location? Wouldn't ariy 
conpetent software engineer distinguish each version of a document (with tig integers signaling 
hag changes and dedmals, v\tether alphabetical or numerical, signaling little ones)? Though 
Gotterbam might have responded angrily to the Committee's suggestion, he offered an 
explanation instead: 

I am a version freak You will note that this code is listed as version 2.1 rather than 2.a 
The diffearonces between this version and v\tot I sent the steering conmttee eadier in the 
week is: the spdUng in the preamble has been corrected, a possessive ^x)strophe [w]as 
removed from the word "opinion's" because it is a plural not a possessive and the 
c^talization used to highlight the changes was removed.^ ^ 

This should have satisfied Fddman Gottedem had almost done just v\tot the Steering 
Committee had asted He had written the cover memo, though in the form of an essay from his 
executive committee, not a memo from the Steering Committee. Gottedam had suggested that 
Fddman should find no fault with the first two paragr^±is of the essay because, after all, they 
were only an abstract of an eadier article, one Barbacd (the first chair of the Steering Committee 
and now an ex offido men±)er because he was lEEE-CS president) had already approved The 
other three paragr^±is in the essay were, while unconnected with Barbacd, basically tme, (more 
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or less) necessary, and pretty much what the Steering Committee seemed to want (a statement of 
what the draft "is and is not"). The code was a draft distributed "to solicit comments"; the 
Steering Committee had reviewed the draft; and so on. Yet Feldman did not immediately 
respond, "Okay, I'll clear this with the Committee as fast as I can." The "cover memo" was now 
a roadblock Gotterbam had to get around— quickly. 

The next day (April 12), a Saturday, Gotterbam emailed Barbacci a page-long email 
(with his email to Feldman and the accompanying documents swelling the message to eight 
pages). He began this email as he had ended the one to Feldman, explaining the differences 
between 2.1 and "2.0a", but then went on to ask that Barbacci "only circulate version 2.1". Since 
Barbacci had been given the web site as his "action", that was a reasonable reminder. But it also 
had the effect of hinting that Gotterbam had the same concem about the Steering Committee that 
it had about him (that they would not be careful enough about keeping versions straight). 
Gotterbam' s next paragraph took Barbacci beyond his own "action". It noted that "the steering 
committee minutes", as Gotterbam understood them, said "that the draft code cannot be 
circulated without an officially sanctioned cover memo." Would Barbacci look at "the 
introduction [below] which I believe serves the purpose of a cover memo"? Gotterbam had, he 
said, "made this suggestion to Stu" but had not heard anything from him yet. "Is there," 
Gotterbam wondered, "any chance of meeting the Monday deadline for SIGCAS?" He then tried 
to make clear how important it was that the answer be yes: "According to the minutes of the 
steering committee, the draft code can only be distributed in an identical form on all media, so 
we cannot move forward until steering committee approval is received for my suggestions below 
[the introductory essay]." 

Gotterbam' s next paragraph retumed to the subject for which Barbacci actually had 
responsibility, publication of the code "on the web". Gotterbam seemed to have understood the 
Steering Committee's plans for publication on the web to include a "chat room" or other 
arrangement allowing people to respond to one another's comments.^^ Gotbertem did not lite the 
idea "I would rather have responses to the draft code and not have commentators engaging in 
acrimonious debates with each other." He feared that the acrimoriy would discourage marry 
would-be commentators from commenting because "[people] are less reticent to express their 
views on morals in a private setting." He then acknov\dedged that "this is more work for us" 
(presumably, "this" being the culling of the comments for ideas rather than letting debate settle 
matters) bit, appealing to his own experience, he pointed out that "we managed to handle this 
kind of email v\ten we did the ACM code of ethics." Gotterbam concluded this discussion of 
web publication by asking v\tot the planned location "at the IEEE site" would be so that he could 
"be more specific in the article below" about how to submit comments. 

Gotterbam's email to Barbacci would seem as cool as the email to Feldman were it not 
for its closing paragr^lt "I really appreciate the prorrptness of your responses. It is fun to work 
on a project that is moving along. Thanks." There followed a "ps": "I wiU get the addresses, 
email, cod fax infomiation for the executive commitiee awardees to you shortly." Why 
Gotterbam did not email ChikDfsky directly is not clean Gotterbam seemed to be treating 
Barbacd as if he vvere still the Steering Ctonmtbee' s chair In ariy case, that is the last vve hear of 
the awards in the emails, though Gotterbam did tate time on Friday to straighten out some email 
addresses. He had tried to mate these changes on April 7 (before sending off the status report), 
working through his George Washington University account Apparentiy, that attenq* had failed 
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The very next day he had received a short response to the status report from someone whom he 
had just removed from the list.''" He now wrote to the person in charge of listservs at ETSU, 
asking that seven addresses be removed (including one rrastatenly assigned to me) and that four 
others be added (n^^ correct address, as well as addresses for Barnes, Jewett, and Wectert)." 
SEEPP no longer consisted of everyone v\to ^plied (and did not resign) . 

Whether Barbacci contacted Fddman, we do not know. What we do know is that 
Fddman responded on Monday (April 14, 1997), about noon, leaving Gottedem time to meet 
the SIGCAS deadline. Fddman began by agreeing that a separate memo was not needed "but" 
(he goes on to say) "we" (presumably, the Steering Committee) "bdieve that it is irrportant to 
explain the ^Dproach, tone, and content of [t]he code" (in the essay). In particular, it was 
inp^rtant to ©qiain that the code was "modded on other codes of ethics for recognized 
professions, that the main purpose of such codes is to educate practitioners about expectations, 
and to clarify the rdations between the professions and the rest of society." For Fddman, "the 
legalistic tone" of such codes was a "natural way to describe such a contract" but did not impty 
that the code will become a "new legal requirement". The Steering Committee's worry, or at 
least Fddman' s, was that the code would be interpreted as a step toward licensure. The Steering 
Committee (or at least some of its members) waried to teep the question of licensure out of the 
discussion. 

The remainder of Fddman's email seems to explain v\^ he took several days to respond 
Having stated the Steering Committee' s purpose in asking for the cover memo, te proposed to 
insert a new paragr^±i in the essay "after the nice introduction about the purpose ard history of 
the IEEE/ACM collaboration". Tte paragr^±i might wdl have taten a busy researcher two days 
to corrpjse. It certainly seems designed to hdp ACM members, especially conpjter scientists, 
to acc^ a code for "software engineers" that does not look much lite the ACM' s code: 

Codes of dhics are common among professions. The draft bdow is modded after several 
adopted by engineering groups. Alttough these codes frequently sound legalistic (almost 
a contract between sodety and the members of the fidd), most are not intended as a 
means of enforcement Rather, Codes of Ethics are, for the most part, descriptions of 
ideal behaviors. They instruct practitioners about the standards that sodety expects them 
to meet, v\tot thdr peers strive for and expect of each other. We hope that the following 
Code vvill be enlightenirig as vvdl as defirdrig a standard vve plan to meet 

One might suppose that Gottedem would have accepted this "friendly amendment" ("friendly" 
in part because the code's preamble says much the same thing). He did not When, late in the 
afternoon, he emailed the SIGCAS Editor the document to be published, it did not contain 
Fddman's paragr^ii Indeed, the introductory essay was exactly as it had been on Friday. 
Gotterbam' s covering letter suggests both his rdid at meeting the deadline and the last-minute 
lobbying that made doing so possible 'Tom, I finally got it settled I phoned some people in the 
US and got clearance!" Gottedem no longer recalls v\tot he said in his phone conversation to 
convince Fddman to abandon his paragr^±L^ ^ 

Gottedem' s files contain an email from Rogerson that seems to explain why Gotterbam 
did not accept Fddman' s paragr^ii The email includes a "snip" from Miller. Preceding the full 
text of Fddman' s paragraph. Miller had written: "I agree [^parently to some comment lost by 
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the snipping]. This makes our code sound even wimpier than it is. I suppose we must bow to the 
pressures and be somewhat spineless. But we don't have to BRAG about it for goodness sake." 
(What seems to have bothered Miller is that Feldman describes the Code as "ideal behavior".) 
Miller then offered this "reword" of Feldman' s paragraph: 

Many professions establish codes of ethics. The draft evolved after extensive study of 
several engineering codes. All these codes try to educate and inspire the members of the 
professional group that adopts the code. The code also informs the public about the 
responsibilities that are important to a profession. Codes instruct practitioners about the 
standards that society expects them to meet and what their peers strive for and expect of 
each other. Codes are not meant to encourage litigation, and they are not legislation; but 
they do offer practical advice about issues that matter to professionals and their clients 
AND THEY DO INFORM POLICY MAKERS.^^ 

RDge3:son told Gotbertem that he preferred "Keith's version" and certainly would "want to 
disassociate niyself from the previous one." His only suggestion is to add tte words in c^:s to 
Miller's version 

A week or so after this crisis, Barbacd emailed Gottedem to ask for "a list of addresses 
(Snail and Email) phones, faxes, etc. for all the people mentioned above [in 2.rs credit 
paragr^±i]". Gotierbam responded (April 24) ty asking everyone on the listserv to provide the 
relevant information, adding (pointedly) that "if you want to have your name removed from the 
list and want to disassociate yourself ftom the code, please do so now.. .[and] yournamewill be 
removed from the list" Responses trickled in The only ones to come through the listserv were 
for Langford (April 24), Mechler (April 28), and me (April 29). 

8.7 Europe responds to Version 2.1 

In May, the International Federation for Information Processing (MP) met in Corfu. On 
May 7, its special interest group (SIG) devoted a session to discussion of Version 2.1. The 
minutes— bearing the bureaucrat's title 'THP SIG9.2.2 'MP Framework on Ethics'"— "record 
the extensive comments" (a page and a half single- spaced).^ * 

After expressing ^Dpredation for the "the effort of the IEEE [sic] task force", it listed 
nine "general observations... made by the group", seven specific "remarls" (organized by 
Principle), and five "Concluding remarks". Some of the geroBl observations sound much lite 
the comments Shaw or Frailey made on Version 1 : "the code needs to have its items prioritized 
in a more evident manner. Items need 'stacking' "; "there are conflicts among some of the items 
included in the code"; "the code represents idealism; then there is realism, the real worid"; 
"marry of the issues raised are not specific to software engineering"; and "the code is really a set 
of guidance notes". Other general observations seem to respond specifically to Version 2.1' s 
innovative Principle 5 ("Management"): "the role of the individual as distinct from the role of 
the organization should be more cleariy delineated"; "would some of the issues be more easily 
incorporated under a code of business ethics?"; and "are some of the issues raised actually about 
the management of large projects?" One of the general observations asks about "enforcement" (a 
question Feldman' s paragr^±i might have averted). The final observation seems to treat as a 

212 



vice one of the virtues of the lEEE-CS/ACM effort, its attempt to involve as many people as 
possible: "some of the names included in the task force appear to be relatively 'new' names to 
the field of ethics". (The IFIP does not say which names appear new, but certainly the new 
names must include Bumstein, Mechler, Prinziavalli, and Fulghum, each of whom had done 
more than some of the well-known names.) 

Many of IFIP's specific remarks took up themes from the general observations. Some are 
concerned with the "realism" of the code, for example: "The goals [of Principle 1] are too high to 
be achieved! What is then the meaning of such a statement? Some paragraphs have nothing to do 
with ethics (1.01 'well documented'; 1.05 'ensure appropriate methodology'... )." Principle 3 is 
"Difficult to implement". Principle 4 requires conduct to be "'consistent with the public 
health,... ' : does this mean Princ, 4 is ranked over Princ. 3 (see 'always act... ')?" Principle 7 
makes "SIG9.2.2" wonder, "How to interpret 7.03 ['Credit fully the work of others '] when 
thinking about Microsoft Windows 95 unreliability, or other well known products? § 7.07 ['Not 
interfere in the professional career progression of any colleague'] is also a bit of wishful thinking 
when compared to practice!" Others are concerned with the code's specificity, for example, 
"Princ. 7 ['treat colleagues fairly']: Being so detailed, why not mention the share of work and 
responsibility with women. Would it be "gender discrepancy'? But, more precisely, SIG9.2.2 
would suggest to insist [sic] on specific software engineering aspects and not on too general 
matters." 

Other remarks seem independent of the general observations, for example: "In our view, 
the emphasis [in Principle 2] must be put on 'disclose the potential danger'. About § 2.06 ['Be 
fair and truthful in all statements, particularly public ones, concerning software or related 
documents' ], one could wonder if it is feasible when we know that software always contains 
errors! We also insist on the difficulty of locating the responsibilities in software development." 
One remark echoes one of Gotterbam's own concerns. "Where [in Principle 3] would you 
include whistle- blowing. In 4.07 ['Inform the client or the employer promptly if, in their opinion, 
a project is likely to fail, to prove too expensive, to violate intellectual property legislation, in 
particular copyright, patent, and trademarks, or otherwise be problematic'].?^^ Wouldn't it be 
better to conader it in a general clause?" The IFIF s remarks on Principle 8 reject Gotberbam' s 
"relational" understanding of the code: "The title 'Self is meaningless: SIG9.2.2 thinks 
'education' would be more ^Dpropriate and needs to be stressed as a principle as such, including 
the present Princ. 8." 

The MF s "concluding remarks" seem to be a set of general recommendations. The code 
should "distinguish the statements that belong to 'Business Ethics in general' and those v\Mch 
are specific to software engineering as such." The "statements [in this code] are individualistic 
[as are those in marry other codes of this kind], v\tereas software engineering is more and more a 
collective task, a work of teams v\tere most of the problems are management problems." The 
code is "too consensual and doesn' t recognize the conflicting world in v\Mch we evolve." How is 
the code to recognize conflict? By, for exanqie, saying something "about the problem of 
ddocalization of software engineering [because] it is a real ethical problem of justice." The code 
would be "better named 'Guidance notes', and surely 'Code of Practice' [would be] better than 
'Code of Ethics' (marry statements have nothing to see [sic] with dMcs; present title is 
misguiding)." The code should be structured so that "the three levels as mentioned in the 
Preamble. . . appear more clearly in the preservation" 
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IFIP's response to Gotterbam's Version 2.1 is (despite differences of detail) so similar to 
the Frailey-Shaw response to Mechler's Version 1 that we must wonder whether the problem lies 
in a certain conception of codes of ethics rather than in the code itself .^'' That conception seems 
to rest on at least three duhaous assunqlions. First, there is some way to settle v\tot should be in 
a code of professional ethics apart from the practical requirements of the profession. So, the 
critics want to omit some matters from the code or call the document something other than a 
"code of ethics". Second, there is a similar presurrglion concerning the specificity of a code of 
ethics. Some rules are either too specific ortoo general for a code of ethics. Third, there seems to 
be an assurr^Dtion that one can ^w that a code of ethics is inpBCtical by pointing out how 
common is conduct that would violate the code if the code were in force ("wishful thinking"). 
The criticism at least seems to ovedook the possitality that a code can change conduct (as well as 
ovedooking the difference between "documenting" standards and "documenting" conduct). 
Insofar as criticism of Version 2 (or Version 1) rests on such a conception of codes, no amount 
of revision is likely to save the code from the criticism. Those favoring the code must either clear 
up the conceptual confusions (a philosophical undertaking) or use procedures to convince critics 
that theirs is a minority view (a political undertaking). 

While these IFIP comments probably did not reach Gotterbam until October, he did 
receive some comments within a few weeks of the IFIP meeting (though these had no connection 
with IFIP). The first to arrive were from even farther away. Weckert emailed a half page from 
Australia on May 14. He thought Principle 1 might need some work: "I'm not sure why 
usefulness is important, unless it is interpreted very broadly and includes things with no 
economic value". He suggested "not harmful" in place of "useful"." Wectert also suggested 
replacing "free of error" with "account for enor" but admitted that "this is a tricky one." He 
ol^ected to "reduction of risk in 1.06. Risk should not just be reduced but reduced "to the 
greatest extent possible". He wondered whose quality of life 2.02 intended: "In marry cases the 
quality of life of the enqioyer might be enhanced (high profits) vMle that of enqioyees 
diminished (loss of jobs or less interesting work). He also wondered v\tether "client's" should 
replace "enqioyer's" in 4.09 ("Represent no interest adverse to their enqioyer^s without the 
eriqioyer^s specific consent, unless ethical considerations demand otherwise "). He concluded 
with a conqiiment ("v\tot you've done is admirable") and an offer to discuss the comments in 
person in June should Gottedem be at either the International Conpjter Ethics Conference at 
Sweden's LinkDpang University or at the Corrpiter Ethics Philosophical Enquiry Conference at 
Erasmus University. GotteriDam was to presenta a p^:er at each, 

8.8 American respjnses 

On May 22, Walter Maner, a professor of corrpiter science at (Ohio's) Bov\ding Green 
State University, sent a brief email. After congratulating Gottedem on the code' s "organization 
and content", te pointed to v\tot he thought was "one large omission". Those software engineers 
that do "human factors" research often use human sutgects. The code should have a section on 
human sutgects research much lite that codes of medical ethics have. There should be something 
about "informed consent, rights of the human sutgect, responsitalities of the experimenter, and 
confidentiality." Maner volunteered to "tate a crack at drafting a set of guidelines". The offer 
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was never taken up. Gotterbam does not recall why but suspects it just got lost in the rush of 
events. Ordinarily, he would have jumped at the chance to work with Maner.^^ 

The next day (May 23), anotter friendly email anived, this one from the Urdvensity of 
Wisconsin at Eau Claire. More than a page-long single spaced, addressed "Dear Mr. Gotterbam", 
and obviously written with considerable care, it was the work of a student, a senior taking Ethics 
in Conpjters. His instmctor (David Neusse) had emailed everyone in the class a copy of the 
code and asted each student to provide feedback directly to Gotterbam" The student had read 
the code. He was "very inp^ssed ty the detail and content". He thought it "definitely an 
irrpDvement over the ACM Code of Ethics" v\Mch he fdt to be sometimes "too general". He 
nonetheless had two "corrgiaints". The first was that Version 2.1 did not stress that "a software 
engineer should always work to achieve the highest quality possible in his/her work". In this 
respect, the ACM code was better. Second, he thought Version 2.1 should have had more to say 
about the privacy of enployee email. The student here seems to have misundenstood v\tot a 
professional code is. It is not a contract with society into which one can insert provisions binding 
society as well as provisions binding members of the profession. It applies only to members of 
the profession. Hence, while it can bind managers who are also software engineers, it can bind 
neither the employer nor the managers who are not software engineers. So, the code can do little 
about the privacy of email. Though he is a mere student, his idea that a code of professional 
ethics should bind society as well as the profession has a long history (going back at least to the 
AMA's 1847 Code of Ethics).'" 

The student nonetheless concedes that a number of rules under Principle 5 address the 
issue "somev\tot". 5.01 tells management to "assure that enployees are informed of standards 
before being held to them" and 5.02 that management "assure enployees know the enployer^ s 
policies and procedures for protecting passwords, files, and other confidential information". But 
he would lite to the code to state "a more explicit policy towards email in the work place." 
Having made his conqiaints, he ends his email ty listing v\tot he lites 'iDest" in the code. All 
three items on his list date from Version 1: First, he lited the 'last set of principles" because "a 
software engineer needs to maintain his con^Detence" and "education does not end with a 
degree". Second he lited Prindpie 6, "about a software engineer's responsitalities to his 
profession", especially 6.13 ("Share useful software-related knov\dedge, inventions, or 
discoveries with the profession, for exanple, ty presenting p^:ers at professional meetings, ty 
publishing articles in the technical press, and by serving on the profession's standard-setting 
bodies") and 6.04 ("Help develop an organizational environment favorable to acting ethically"). 
Last, he was glad to see "conc^fc" included in Version 2.1 that were missing from the ACM 
code, in particular "an enphasis on documentation and testing of software", "having qualified 
people work on a project", "warning the public about the dangers and risks associated with 
conpjters", and "[not asking] enployees to do something inconsistent with the Software 
Engineering Ethics Code". 

Within a week, two more emails arrived from Eau Claire. On May 26, "Student 2" sent a 
half page of comments. HsarenMchnrnregeneralthanStudentl's. The introductory essay says 
that "v 2.1" is based on several other conprting and engineering codes. He would lite to have 
the source of each particular provision somehow identified within the code (peih^:s as 
annotations) . (No doubt, he would have been h^Dpy with something lite the table Gotterbam sent 
the Steering Committee in February.) Student 2 would also lite to know v\tot moral theory the 
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codes in question were based on, for example, "were [they] based on Kantian or Utilitarian 
principles"? The Preamble mentions three levels of ethical obligation but "there is a deficit of 
pragmatic examples that could potentially identify and illustrate [the] ethical obligations." He 
would like to see some "real life computer related examples" to help the reader "identify with 
them". Last Student 2 wondered whether the list of keywords might be "too extensive in 
number". Perhaps some of "the ideas would best be presented in paragraph format with the intent 
of enticing the readers... [to] process this information." 

The last email to arrive from Eau Claire is even shorter. While "Student 3" liked the code 
over all, he had two critical comments. First, he thought Principle I's statement that software 
should be "free of error" was unrealistic: "Is there really any large software package that can be 
'free of error'?" Second, he was not clear how the code was to be used. As he read the code, it 
seemed to say that the software engineer should eliminate all problems at the beginning of the 
project. He was concerned about what to do if the problems arose thereafter. He knew that the 
code does not cover "all possible scenarios, but problems are inevitable." One solution, he 
suggests, is "to recursively use the code until the project is done." 

8.9 Mechler checks in 

Those were the only comments Gotterbam received on the code in May. The same was 
true of early June, as Gotterbam began to pack in preparation for the end of his sabbatical leave 
and return to Tennessee. Then, on June 19, there was a flurry of emails, beginning with a short 
email from Mechler at 8:18 AM (EDT) to Gotterbam's "computer.org" address: "This is a test 
from ethics page on IEEE. The address for you was old and I wanted to see if you were getting 
any comments. Let me know if you get this email." Twenty minutes later, Mechler emailed the 
SEEPP listserv: "I do not know if I missed an e-mail reporting the placement of the code on the 
net. The top web address [at the top of this email] is for the committee which leads to the code 
and the bottom [also at the top of the email] is the code." An hour later, Mechler emailed 
Gotterbam again asking whether Gotterbam had received the email he sent from the web page 
(the 8:18 email) or the one he had sent through the listserv twenty minutes later. Mechler was 
writing because he "could not find a reference on lEEE-CS home page so I search[ed] on ethics. 
The CS pages are so numerous people may never see the Code. Have you received any 
comments yet?" 

Within a few minutes of receiving this second email, Gotterbam responded to Mechler' s 
tests: "I received you[r] email. I now have at least three addresses all of which find me where 
ever I am. Thanks for remindin[g] me about the web site. I will send a message to the group. 
He then sent the listserv a status report: 

Sorry to have been slow about this. The Draft code is out for comment in several 
domains. 

It is on the ACM web site www.acm.org in the serving the community area. 

It is, as Ed indicated, on the IEEE web site, but somewhat hard to find. 

It has been published in the June issue of the SIGCAS Newsletter and is coming 

out in the SIGSOFT newsletter. 
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It should also be out soon in the TCSE-IEEE newsletter. I believe this is the 
largest IEEE-Computer Society technical group. 

All of these presentations ask for comments. There have been no responses yet. 
We will organize the comments when they start to come in and present them to the task 
force for discussion and vote. We have not had any new comments from any steering 
committee member. 

Not much else new. 

Apparently, Gotterbam had forgotten the comments received a month ago from Walter Maner 
and from the three students in Eau Claire. While only Maner' s could count as a response to the 
"presentations", all could count as something "new". 

A few minutes after sending out this report, Gotterbam received another email from 
Mechlen "I have my son at Vanguard passing the code around and I am sending e-mail to SEs at 
ERI [where Mechler then worked]. Maybe the task force should send to friends, etc."^^ 
Mechlei^s activity seemed a good omen Suidy, around the vvoild, there vveie a few thousand, or 
at least a few hundred, people v\to, seeing tte code in one of the publications, would tate the 
time to respond in much the way the three students at Eau Claire had The task force might have 
to sift through a mountain of comments; it would certainly have to do one more draft But 
Gotbedam could now see the end of the proj ect He was already making arrangements to publish 
"Vension 3.0" with ballots in Communications of the ACM and IEEE Computer in September or 
October. He was more or less still on schedule. The project should be over by the end of 1997." 

Eariy in July, v\ten Gotbedem boarded a plane at Heathrow for the long flight home, he 
had only a few worries. The first, and most inpjrtant, was the continued silence of the Steering 
Committee. Except for the April request for a "cover memo", it had given no direction since it 
made him SEEPF s sole chair on January 6. It had not interfered, v\Mch suggested that it did not 
dis^Dprove of v\tot he was doing. His version of the code had not had to face the hostile response 
that Mechler' s version had But the Steering Committee had also not done ariything to help, had 
not formally approved the schedule he had proposed or provided the budget as he had asted No 
matter how much he tried, he could not get the Committee to show real commitmenL The May 
31 deadline for comments from the Steering Committee had passed without ariyone on the 
Committee commenting on anything. He wondered how committed the Commitbee was to 
devdopng a code. He wondered v\teher he should proceed without express ^proval of v\tot he 
was doing. Pahaps he was being too formalistic. When, during a phone conversation, he asked 
Barbacci v\teher he should wait for the Steering Committee' s approval before proceeding with 
publication of Version 3, Barbacci had responded something lite, "Sometimes you just have to 
do it The job gets done and it is easy to apologize."" Perii^DS Barbacci was right Gotteatam 
had in fact been doing just that since he arrived in England— and look v\tot he had achieved in 
less than six months! 
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8. Appendix: 

Draft Software Engineering C ode of Ethics 

Don Gotterbarn, Keith Miller, Simon Rogerson 

version 2.1 
April 1997 



In May of 1993, the Board of Governors of the lEEE-CS established a steering 
committee for evaluating, planning, and co-ordinating actions related to establishing software 
engineering as a profession. In that same year the ACM Council endorsed the establishment of a 
Commission on Software Engineering. By January of 1994, both societies formed a joint 
committee "To establish the appropriate set(s) of standards for professional practice of Software 
Engineering upon which industrial decisions, professional certification, and educational curricula 
can be based." To accomplish these tasks they made the following recommendations: 

1. adopt standard definitions 

2. define required body of knowledge and recommended practices 

3. define ethical standards 

4. define educational curricula for undergraduate, graduate(MS) and continuing 
education (for retraining and migration). 

The steering committee decided to accomplish these tasks through the establishment of a 
series of task forces. Initially the task forces established were: Software Engineering body of 
knowledge and recommended practices; Software Engineering ethics and professional practices, 
and Software Engineering curriculum. 

The purpose of the ethics task force is to document the ethical and professional 
responsibilities and obligations of software engineers. This draft code of ethics was developed by 
a task force of the Joint IEEE Computer Society and Association for Computing Machinery 
Steering Committee for the Establishment of Software Engineering as a Profession. The task 
force on Software Engineering Ethics and Professional Practices developed this code for a sub- 
specialization within the constituencies of both of the professional societies. In an attempt to 
reflect the international character of both organizations and the profession itself, the composition 
of the task force is multinational in both citizenship and in membership in professional 
computing organizations. The proposed draft Code of Ethics for Software Engineers ( version 
2.1 ) was developed by the task force and reviewed by the Steering Committee for distribution 
and comment as a preliminary draft. The intent of this distribution is to solicit comments from 
practitioners and other interested parties. 

The draft evolved after extensive study of several computing and engineering codes. All 
these codes try to educate and inspire the members of the professional group that adopts the 
code. The code also informs the public about the responsibilities that are important to a 
profession. Codes instruct practitioners about the standards that society expects them to meet, 
and what their peers strive for and expect of each other. Codes are not meant to encourage 
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litigation, and they are not legislation; but they do offer practical advice about issues that matter 
to professionals and their clients and they do inform policy makers. Based on the feedback from 
readers of this publication and from other sources, a final draft of the code will be developed and 
presented to the Steering Committee for approval. 



PREAMBLE V 2.1 

Computers now have a central and growing role in commerce, industry, government, 
medicine, education, entertainment, social affairs, and ordinary life. Those who contribute, by 
direct participation or by teaching, to the design and development of software systems have 
significant opportunities both to do good and to cause harm and to influence and enable others to 
do good or cause harm. To assure, as much as possible, that this power will be used for good, 
software engineers must commit themselves to making the design and development of software a 
beneficial, and respected profession. In accordance with that commitment, software engineers 
shall adhere to the following Code of ethics. 

The Code contains eight keyword Principles related to the behavior of and decisions 
made by professional software engineers, be they practitioners, educators, managers and 
supervisors, or policy makers, as well as trainees and students of the profession. The Principles 
identify the various relationships in which individuals, groups, and organizations participate and 
the primary obligations within these relationships. 

Each Principle of this code addresses three levels of ethical obligation owed by 
professional software engineers in each of these relationships. The first level identified is a set of 
ethical values which they share with all other human beings by virtue of their humanity. The 
second level obliges professionals to a higher order of care for those who may be affected by 
their work. The third and deeper level comprises several obligations which derive directly from 
elements unique to the professional practice of software engineering. The Clauses of each 
Principle are illustrations of the various levels of obligation included in that relationship. 

The Clauses under each Principle consist of three different types of statement 
corresponding to each level. Level One: Aspire (to be human); Statements of aspiration provide 
vision and objectives, are intended to direct professional behavior. These directives require 
significant ethical judgement. Level Two: 

Expect (to be professional); Statements of expectation express the obligations of all 
professionals and professional attitudes. Again they do not describe the specific behavior details 
but they clearly indicate professional responsibilities in computing. Level Three: Demand (to 
use good practices); Statements of demand assert more specific behavioral responsibilities within 
software engineering which are more closely related to the current state of the art. The range of 
statements is from the more general aspirational statement to specific measurable requirements. 

Although all levels of professional obligation are recognized and because the Code 
contains different types of statements, the Code is not intended to be all inclusive nor is it 
intended that its individual parts be used in isolation to justify errors of omissions or 
commission. The list of Principles and Clauses is not exhaustive, and should not be read as 
separating the acceptable from the unacceptable in professional conduct in all practical 
situations. The Code is not a simple ethical algorithm which generates ethical decisions. In some 
situations standards may conflict with each other or with standards from other sources. These 
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situations require the software engineer to use ethical judgement to act in a manner which is most 
consistent with the spirit of the code of ethics, given the circumstances. 

These ethical tensions can best be answered by thoughtful consideration of fundamental 
principles, rather than reliance on detailed regulations. These Principles should influence you to 
consider broadly who is affected by your work; to examine if you and your colleagues are 
treating other human beings with due respect; to speculate on how the public would view your 
decision if they were reasonably well informed; to analyze how the least empowered will be 
affected by your decision; and to consider if your acts would be considered worthy of the ideal 
professional working as a software engineer. Since this code represents a consensus of those 
engaged in the profession one should take into account what is likely to be judged as the most 
ethical way to act in the circumstances by informed, respected, and experienced peers in 
possession of all the facts and only depart from such a course for profound reasons, backed with 
careful judgement. 

The dynamic and demanding context of software engineering requires a code that is 
adaptable and relevant to new situations as they occur. But even in this generality, the code 
provides support for the software engineer who needs to take positive action by documenting the 
ethical stance of the profession; an ethical foundation to which individuals within teams and the 
team as a whole can appeal. The code also helps to define those things which are ethically 
improper to request of an software engineer. 

The code has an educational function, stating what is required of anyone wishing to join 
or continue in the software engineering community. Because it expresses the consensus of the 
profession on ethical issues it can be used as a guide to decision making and as means to educate 
both the public and aspiring professionals about the professional obligation of all software 
engineers. 



PRINCIPLES V 2.1 

Principle 1: PRODUCT 

Software engineers shall, insofar as possible, assure that the software on which they work 
is useful and of acceptable quality to the public, the employer, the client, and the user, completed 
on time and at reasonable cost, and free of error. In particular, software engineers shall, as 
appropriate: 

1.01. Ensure that specifications for software on which they work have been well 
documented, satisfy the user's requirements, and have the client's approval. 

1 .02. Strive to understand fully the specifications for software on which they work. 

1 .03. Ensure that they are qualified, by an appropriate combination of education and 
experience, for any project on which they work or propose to work. 

1.04. Ensure proper and achievable goals and objectives for any project on which they 
work. 

1.05 Ensure an appropriate methodology for any project on which they work or 

propose to work. 
1 .06. Ensure good management for any project on which they work, including effective 

procedures for promotion of quality and reduction of risk. 
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1.07. Ensure realistic estimates of cost scheduling, personnel and outcome on any 
project on which they work or propose to work and provide a risk assessment of 
these estimates. 

1.08. Ensure adequate documentation on any project on which they work, including a 
log of problems discovered and solutions adopted. 

1.09. Ensure adequate testing, debugging, and review of software and related 
documents on which they work. 

1.10. Work to develop software and related documents that respect the privacy of those 
who will be subjected to that software. 

1.11 Be careful to use only accurate data derived from legal sources and use only in 
ways properly authorized. 

1.12 D elete, whenever appropriate, outdated or flawed data. 

1.13. Work to identify, define and address ethical, economic, cultural, legal, and 
environmental issues. 

1.14. Promote maximum quality and minimum cost to the employer, the client, the 
user, and the public and make any tradeoffs clear to all parties concerned. 

1.15. Work to follow industry standards that are most appropriate for the task at hand, 
departing from these only when technically justified. 



Principle 2: PUBLIC 

Software engineers shall, in their professional role, act only in ways consistent with the 
public safety, health and welfare. In particular, software engineers shall: 

2.01. Disclose to appropriate persons or authorities any actual or potential danger that 
they reasonably believe to be associated with the software or related documents 
on which they work, or are aware of, may pose to the user, a third party, or the 
environment. 

2.02. Approve software only if they have a well-founded belief that it is safe, meets 
specifications, has passed appropriate tests, and does not diminish quality of life 
or harm the environment. 

2.03. Affix their signature only to documents prepared under their supervision or within 
their areas of competence and with which they are in agreement. 

2.04. Co-operate in efforts to address matters of grave public concern in software or 
related documents. 

2.05 Endeavor to produce software that respects diversity. Issues of language, different 

abilities, physical access, mental access, economic advantage, and allocation of 
resources should all be considered. 

2.06. Be fair and truthful in all statements, particularly public ones, concerning 
software or related documents. 

2.07. Not put self-interest, the interest of an employer, the interest of a client, or the 
interest of the user ahead of the public's interest. 

2.08. Feel free to donate professional skills to good causes. 

2.09. Accept full responsibility for their own work. 
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Principle 3: JUDGMENT 

Software engineers shall, insofar as possible and consistent with Principle 2, protect both 
the independence of their professional judgment and their reputation for such judgment. In 
particular, software engineers shall, as appropriate: 

3.01 Maintain professional objectivity with respect to any software or related 

documents they are asked to evaluate. 

3.02. Affix their signature only to documents prepared under their supervision and 
within their areas of competence. 

3.03. Reject bribery. 

3.04. Accept no payback, kickback, or other payment from a third party to a contract, 
except with the knowledge and consent of all parties to the contract. 

3.05. Accept payment from only one party for any particular project, or for services 
specific to that project, except when the circumstances have been fully disclosed 
to parties concerned and they have given their informed consent. 

3.06. Disclose to all concerned parties those conflicts of interest that cannot reasonably 
be avoided or escaped and aspire to resolve them. 

3.07. Participate in no decision of a governmental or professional body, as a member or 
advisor, concerned with software, or related documents, in which they, their 
employer, or their client have a financial interest. 

3.08 Temper all technical judgements by the need to support and maintain human 

values. 



Principle 4: CLIENT AND EMPLOYER 

Software engineers shall, consistent with the public health, safety, and welfare, always 
act in professional matters as faithful agents and trustees of their client or employer. In 
particular, software engineers shall: 

4.01 . Provide service only in areas of their competence. 

4.02. Assure that any document upon which they rely has been approved by someone 
authorized to approve it. 

4.03. Use the property of a client or employer only in ways properly authorized, and 
with the client's or employer's knowledge and consent. 

4.04. Not knowingly use illegally obtained or retained software on equipment of a 
client or employer or in work performed for a client or employer. 

4.05. Keep as confidential information gained in their professional work that is not in 
the public domain (and is not inconsistent) , where such confidentiality is 
consistent with matters of public concern. 
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4.06. Identify, document and report to the employer or the client any problems or 
matters of social concern in the software or related documents on which they 
work or of which they are aware. 

4.07. Inform the client or the employer promptly it in their opinion, a project is likely 
to fait to prove too expensive, to violate intellectual property legislation, in 
particular copyright patent and trademarks, or otherwise be problematic. 

4.08. Accept no outside work detrimental to the work they perform for their primary 
employer. 

4.09. Represent no interest adverse to their employer* s without the employer* s specific 
consent , unless ethical considerations demand otherwise. 



Principles: MANAGEMENT 

A software engineer in a management or leadership capacity Shall act fairly and shall 
enable and encourage those who they lead to meet their own and collective obligations, including 
those under this code. In particular, those software engineers in leadership roles shall as 
appropriate: 

5.01 . Assure that employees are informed of standards before being held to them. 

5.02. Assure employees know the employer* s policies and procedures for protecting 
passwords, files, and other confidential information. 

5.03. Assign work only after taking into account appropriate contributions of education 
and experience. 

5.04. Provide for due process in hearing charges of violation of an employer's policy or 
of this code. 

5.05. Develop a fair agreement concerning ownership of any software artifact an 
employee has contributed to. 

5.06. Attract employees only by full and accurate description of the conditions of 
employment 

5.07. Offer only fair and just remuneration. 

5.08. Not unjustly prevent a subordinate from taking a better job for which that 
subordinate is qualified or experienced to do. 

5.09. Not ask an employee to do anything inconsistent with this code. 



Principle 6: PROFESSION 

Software engineers shall, in all professional matters, advance both the integrity and 
reputation of their profession as is consistent with public health, safety, and welfare. In 
particular, software engineers shall, insofar as possible: 

6.01 . Associate only with reputable businesses and organizations. 
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6.02. Assure that clients, employers, and supervisors know of the software engineer* s 
commitment to this code of ethics, and their own responsibility under it. 

6.03. Support those who similarly do as this code requires. 

6.04. Help develop an organizational environment favorable to acting ethically. 

6.05. Report anything reasonably believed to be a violation of this code to appropriate 
authorities. 

6.06. Take responsibility for detecting, correcting, and reporting errors in software and 
associated documents on which they work. 

6.07. Only accept remuneration appropriate to professional qualifications or experience. 

6.08. Be accurate in stating the characteristics of software on which they work, 
avoiding not only false claims but claims that might reasonably be supposed to be 
deceptive, misleading, or doubtful. 

6.09. Not promote their own interest at the expense of the profession. 

6.10. Obey all laws governing their work, insofar as such obedience is consistent with 
the public health, safety, and welfare. 

6.11. Exercise professional responsibility to society by constructively serving in civic 
affairs. 

6.12. Promote public knowledge of software engineering. 

6.13. Share useful software- related knowledge, inventions, or discoveries with the 
profession, for example, by presenting papers at professional meetings, by 
publishing articles in the technical press, and by serving on the profession's 
standard- setting bodies. 



Principle?: COLLEAGUES 

Software engineers shall treat all those with whom they work fairly and take positive 
steps to support these collegial activities. In particular, software engineers shall, as appropriate: 

7.01 . Assist colleagues in professional development. 

7.02. Review the work of other software engineers, which is not in the public domain, 
only with their prior knowledge, provided this is consistent with safety. 

7.03. Credit fully the work of others. 

7.04. Review the work of others in an objective, candid, and properly- documented way. 

7.05. Give a fair hearing to the opinion, concern, or complaint of a colleague. 

7.06. Assist colleagues in being fully aware of current standard work practices 
including policies and procedures for protecting passwords, files, security 
measures in general, and other confidential information. 

7.07. Not interfere in the professional career progression of any colleague. 

7.08. Not take steps to supplant another software engineer after steps have been taken 
for employment. 

7.09. In situations outside of their own areas of competence, call upon the opinions of 
other professionals who have competence in that area. 
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Principles: SELF 

Software engineers shall, throughout their career, strive to enhance their own ability to 
practice their profession as it should be practiced. In particular, software engineers shall 
continually endeavor to: 

8.01. Further their knowledge of developments in the design, development, and testing 
of software and related documents, together witii the management of the 
development process. 

8.02. Improve their ability to create safe, reliable, and useful quality software at 
reasonable cost and within a reasonable time. 

8.03. Improve their ability to write accurate, informative, and literate documents in 
support of software on which they work. 

8.04. Improve their understanding of the software and related documents on which they 
work and of the environment in which they will be used. 

8.05. Improve their knowledge of the law governing the software and related 
documents on which they work. 

8.06. Improve their knowledge of this code, its interpretation, and its application to 
their work. 

8.08. Not require or attempt to influence any person to take any action which involves a 
breach of this code. 

8.09. Consider violations of this code inconsistent with being a professional software 
engineer. 



This draft Code was developed by the ACM/IEEE-CS joint task force on Software 
Engineering Ethics and Professional Practices: 

Chair: Donald Gotterbarn 

Executive Committee: Keith Miller and Simon Rogerson 

Members: Peter Barnes, Steve Barber esq., Ilene. Bumstein, Amr 
El-Kadi, N.Ben Fairweather, Milton Fulghum, N. Jayaram, Tom 
Jewett, Maj. Mark Kanko, Ernie Kallman, Duncan Langford, Joyce 
Currie Little, Ed Mechler, Manuel J. Norman, Douglas Phillips, 
Peter Ron Prinzivalli, Patrick Sullivan, John Weckert, 
S.Weisband, and Laurie Honour Werth 
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Please send comments on this draft of the Preamble and the Code 

to: 
Donald Gotterbam 
Computer and Information Sciences 
East Tennessee State University 
Box 70711 

Johnson City, TN 37614-0711 
d.gotterbam(5) computer.org 
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NOTES 

^ Wolfs law seems to be a special case of the "Iron Law of OligarcliT", so named by 
Robert Mchds, A Sociological Study of the Oligarchical Tendencies of Modern Democracy 
(Dover: New York, 1962), originally published in 1915. 

^ Steering Conimittee\Schediile\SCHEDv2. "GotteriBm\History of SE Code\History 

expanded" informs us that the document was sent to the Steering Committee. The Steering 
Committee minutes for Febmary 1997 are silent about its reception (and also unusually brief 
about other matters) . 

^ Eariier versions of the Schedule go back to a Febmary 2, 1997 draft for circulation within 

the executive committee: GottertamWersion l\Schedule vl (v\Mch includes some jotes). 
MUer^s email of February 10 concluded with a comment on one of those eariier versions: the 
"schedule seems fine" but "[you] know the politics, I don't Urq^d work for all of us, and it 
seems like lots of it (especially for you), but do v\tot you have to do, and teU me v\tot to do 
v\terL" 

^ In comments on this ch^Dter (then nmnbered "7"), GotteriDam cautioned: "The 

description you dte about experts was an oversinqiified way to describe v\tot I did as 
reorganization v\Mch was sent to the Steering committee. TMnk of the difficulties you have had 
with the events I described in 1-4 [now 2-5] above and it will be clear v\^ I did not try to 
explain stuff about the list serve to the steering committee." Gotteatam Ch^Dter7cmt (September 
30, 2004). 

^ For some reason, the "three areas" have become two. Perii^Ds Gottertem himself 

represents the third ("academic coordinator^'?). 

^ That is hardly an overstatement For exanqie. Barber recalls: "I was assigned to a 

working group for one of the principles, but I dont believe that the working group ever met by 
the time I told Don that I wouldn't be actively participating in SEEPP any more." Interview of 
Barber, November 14, 2002, answer to question 8. Note that Barber seems to believe that there is 
some connection between the code' s "Principles" and the original working groups. 

' The list of experts by nationality is a hat odd On the one hand, v\to (but a Scot lite 

Rogerson) would count Scotiand a counhy (or nation) separate from England? What h^Dpened to 
the "United Kingdom"? On the other hand, Gotterbam's eariy lists of applicants did include 
several from the Irish Republic. Why no mention of these? Thete are other oddities as well. For 
exanple, none of Gottabam's lists ever included ariyone from Germariy (though a Swiss 
eventually does comment). Had he made some new contacts (v\to, though seemingly promising 
then, did not fulfill their promise)? In comments on this ch^Dter, Gottertem described the panel 
of experts as the Professional Practices Task Force "enlarged by addition of working group 
leaders— with the exception of Mdford— v\to should have been familiar with v\tot was going 
on." Gotteatam Ch^Dter7cmt (September 30, 2004) The nationalities listed (and omitted) suggest 
aconqiex (or haphazard) enlarganent 
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^ Gotte±)am would have had particular trouble with this last question Miller does not seem 
to have coordinated anything. In fact, he seems to have been pretty distant from the 
administrative side of all SEEPFs work His Febmaiy 10, 1997 memo specifically declared an 
indifference to politics (in an exchange on Principle 1): 'If it [the substitution of 'insofar as 
possible' for 'significant' ] is politically required, leave it I still don't lite it, and you know v\^, 
but the politics are unknown to me, and I'd lite to teep it that way." Another exarrple of 
Miller' s distance from SEEPP is a March 18, 1997 email to Gottedem: 

When I was at the APPE conference in DC, I talted to Vivian Weil of the Illinois 
Institute of Technology. She has been interested in our long and arduous adventure trying 
to bang out an ethics code. I told her in general about some of our difficulties, but I f dt 
uncomfortable about going into smy specifics since I don't know how much of what we 
have discussed and emailed is corfidential. . . . Anyway, would you please email Vivian 
and give her a thumbnail stetch of v\tof s been going on? Also, if you think it is 
appropriate, add her to the list of people getting copes of our code drafts. She is: 
weil(a)chariie.cns.iitedu. 

Apparentiy, Miller did not know (or had forgotten) v\to was on Gottedem's "panel of experts" 
or how much trouble Gottedem had had with that particular email address (and its kin) . He also 
seems to have forgotten that Weil had been a member of his own working group and so someone 
for whom Gotteibam (as SEEPP chair) should already have had an address. 

" Gotterbam Ch^]ter7cmt (September 30, 2004). 

^° In fact, v\tot was soon known as the "Software Engineering Education Project' (SWEEP) 
would conqiete work on accreditation criteria in November 1998. For details, see Gerald L. 
Engd, "Program Criteria for Software Engineering Accreditation Programs", IEEE Software 
November/December 1999: 31- 34. 

' ' Though Coccli' s work at IBM concerned Java (and similar programming) languages, he 
was trained as an engineen B. EE. (Pratt Institute), 1964, and M. EE (Pratt Institute), 1967. Two 
decades later, he did receive a master' s degree in conpjter science from New York Polytechnic, 
but still considered himself an engineer— "unless you use my distinction between engineer and 
scientist [as I do:] An engineer delivers things on time, on budget, and on function Scientists do 
experimental work. I do experimental work." Interview of Coccli, Noven±)er 12, 2002. 

'^ Minutes of Steering Committee (February 1997). Douglas and Cocchi submitted their 
report on the "Pilot Survey" on March 27, 1997, an inpjsing document of more than a hundred 
pages. 

' ^ On April 18, 2001, the lEEE-CS published a trial version of the Guide to the Software 
Engineering Body of Knowledge (www.swebok.org). For details of development through 1999, 
see Bourque et al., "The Guide of the Software Engineering Body of Knov\dedge", IEEE 
Software, November/December 1999: 35-50. 
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^^ The dissertation's title was: The Relation of Green Moral and Political Theory to Liberal 
Moral and Political Theory. 

'^ Eventually published under that title in G. CoUste, ed. Ethics in Information Technology 
(Linkoping University Press, 2000), pp. 259-277; and reprinted in Terrance Ward Bynum and 
Simon Rogerson, Computer Ethics and Professional Responsibility (Oxford: Blackwell, 2003), 
pp.142-155. Though this is how Fairweather remembers the circumstances when Gotterbam 
arrived (Interview with Fairweather, February 25, 2003), Gotterbam remembers it a bit 
differently: "Check this fact: Last time I was at CCSR website— the site had a list of computer 
Codes— Australian Code etc, which I brought with me to CCSR, Ben had not been looking at 
these prior to my arrival." Gotterbam Chapter7cmt (September 30, 2004). Unfortunately, there 
seems to be no way to reconstmct what was on the site when Gotterbam arrived. We may, I 
think, safely assume that some of the codes now present, such as NSPE code, were already there 
(and that they would have been enough for Fairweather' s purposes at that time). 

' ^ Interview with Fairweather, Febmary 25, 2003. 

Interview with Prior, Febmary 24, 2003. 

' ^ Interview with Prior, February 24, 2003. 

' ^ Interview with Fairweather, February 25, 2003. 

^° GotteriDam wonders v\teher there is a single explanation of this disagieement: 
Fairweather, he thinks, may have communicated with Rogerson orally more than with him 
Comments on (v\tot was then) Ch^Dter 7 (September 22, 2003). 

^' Langford declined to be interviewed and gave the impression that he had not done much. 
"Much" is, of course, a relative term. We may gauge Langford's participation from just one 
example, his page-long email commenting on Version 2.0 that arrived on Febmary 28, 1997. His 
suggestions were: revising the Preamble to read "free from KNOWN error"; replacing "aspire" 
in 1.10 and 1.14 with "work" ("aspire" being too "weak"); deleting "authorities" in 2.01 
because "they would automatically be the 'appropriate persons'; deleting "and " after "meets 
specifications, and" in 2.02; replacing "should" with "must" in Principle 3; adding a reference to 
"law" in the Preamble's "consistent with the public, health, safety, and welfare"; revising 6.02 
by adding "prior" before knowledge; and adding "and appropriately" after "credit fully" in 6.03. 
Gotterbam accepted many of these. 
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Email, March 17, 1997. 



^ ^ Gotterbam credits Miller with being "responsible for much of the excellent rhetoric of the 
preamble. Septen±)er 22, 2003 comments on Ch^Dter 7. 
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^^ Do the draftens really mean that one can be a software engineer without designing or 
devdopng software but sinply "by teaching" some course to software engineers (Java or even 
philosophy)? What is it to "contribute" to the design or development of software by teaching? 
Has the "academic lobby" gone too far here? 

^ ^ What h^Dpened to "test"? Don't software engineers test software? Or was testing sinply 
assumed to be part of designing and devdopng? Explaining this change would have been 
helpful. After all, testing is such an inp)rtant part of operation and maintenance as well as 
design and development that it often receives separate mention in descriptions of software 
engineering, for exanqie, "[software engineers] specialize in designing, building, testing, and 
'maintaining' software products." David Lorge Pamas, "Software Engineering Programs Are 
Not Conpjter Science Programs", IEEE Softvjare, November/December 2001: 19-30, at p. 20. 
Gotterbam's definition is almost as distant from the official definition of "software engineering" 
quoted in Chapter 2.6: "The application of a systematic, disciplined, quantifiable approach to the 
development, operation, and maintenance of software; that is, the application of engineering to 
software.") That definition, while omitting "testing", does include (as Gotterbam's does not) 
"operation" and "maintenance"? We may expect the Preamble's definition of software 
engineering to develop in succeeding versions. Lists like this are politically important. They 
recognize groups, especially substantial ones that that want to be remembered. 

^ ^ In comments on the first draft of this ch^Dter (September 22, 2003), Gotterbam offered a 
different reading of this "must" as something lite the logical "if and only if" rather than a 
command: "You ain't a professional software engineer without this commitmenL" I agree with 
Gotterbam's claim about v\tot is necessary to be a professional software engineer, but I don't 
think his use of "must" here mates that point My ear and his seem to differ (though we are both 
native speatere of American English), a reason to find another way to express the point we both 
agree on 

^ ' The switch from "must" in the third sentence to "shall" in the fourth invites the question 
whether the drafters irteid "must" to mean the same as "shall" (as it generally does) or 
something different That is a question more care in drafting could have avoided Plainly, we are 
still dealing with a "first draft". 

^^ The two sentences were: "The seven main paragraphs state general rules. Each 
subsidiary clause is a specific ^plication of its general rule, one experience has shown needs 
express statement but no set of subsidiary clauses exhausts the general rule." 

^^ Fairweather (^parently seeing the problem noted here) suggested replacing "Aspre (to 
be human)" with "Aspre (as a human"). Gottertem rejected this suggestion and a related one, 
replacing "Expect (to be professional)" with "Expect (as a professional)". Apparently, he did not 
see the problem— or at least did not see the change proposed as a solution to it 
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^° Gottedem "[I] later discovei[ed] that enphasis on three levels of ethics caused probleiiis 
because everyone warited the code clauses to be assigned to a specific level." Gotte±iam\Histoiy 
of SE Code\Expanded Hstoiy of SE Code. WMle the ACM code also distinguishes between 
several levels, its analysis of those levels is different from Aspre, Expect, and Demand Its 
Preandie states: "[This code] contains many, but not all, issues professionals are liMy to face. 
Section 1 outlines fundamental ethical considerations, vMle Section 2 addresses additional, more 
specific considerations of professional conduct Statements in Section 3 pertain more specifically 
to individuals v\to have a leadership role, v\tether in the woilqiace or in a volunteer cspddty, 
for exanqie with organizations such as ACM. Principles involving conqiiance with this Code 
are given in Section 4." 
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Comments on Chapter 7, September 22, 2003. 



^^ Cto the sarne day, Gotterbam sent nie the form letter beginning 'Ton have been added to 
the PRFCMP-L mailing list" with the correct address csep(a)chaiiie.cns.iitedu. 

^^ According to Gotterbam, the status report is a routine part of managing a software 
engineering project. The purpose of the report is to identify and address problems. But a "status 
report can only be issued when you have a project plan to report on." The project plan (the one 
that the Steering Committee had never approved or rejected) was originally developed to 
accomplish three purposes: "1. it helps keep the project organized. 2. it enables the identification 
of who— where there are failures. 3. it sets a schedule— so if you (the steering committee) are 
serious about meeting a schedule then here is what you must do, if the project fails and— as 
indicated in the status report— you did not do your job, then there is no question as to who is 
responsible." Comments on Chapter 7, September 22, 2003. Though Gotterbam had been giving 
the Steering Committee status reports all along, he had never before given one without being 
asked to do so. In this respect, this status report is not routine. It is also not routine in reporting 
on a plan that remained unapproved. Until then, Gotterbam had always reported on progress in 
carrying out a plan the Steering Committee had approved. Gotterbam was, it seems to me, in part 
using the Status Report to push the Steering Committee— and, if they did not do as he wanted, to 
be sure the blame would be theirs, not his. I stress "it seems to me" because Gotterbam does not 
agree with this reconstmction of his motivation. 
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Comments on Chapter 7, September 22, 2003. 



^^ Comments on Ch^Dter 7, September 22, 2003. Note that Gotterbam also seems to have 
given up on getting the Schedule ^proved but nonetheless is not only trying to teep to it himself 
but (at last) has found a way to tell SEEPP exactiy v\tot it says— by the perf ectiy standard act of 
copying SEEPP v\ten he sent the report to the Steering Committee. 

^ ^ A conparison of Version 2.0a' s Preamble with Fairweather' s proposals for revising the 
first draft, reveals a similar pattern Gotterbam accepted some suggestions (those he had 
chected) and rgected others (ttose beside which he had put an x or question mark). 
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^^ The spelling of "judgement" ( "e" after the "g") suggests a British origin for the language 
in CAPS. Arri, indeed, the language in CAPS ^Dpeais among Fairweathei^ s suggestions. 

^^ What "with careful judgement" adds to "profound reasons" is unclear. The suggestion 
seems to be that the software engineer must not only have good reasons for departure from the 
consensus (a substantive criterion) but must also have considered the departure carefully (a 
procedural criterion). 

^^ The "as appropriate" is, of course, redundant, since all clauses under Principle 1 are 
preceded by "as ^Dpropriate". Redundancy, though inelegant, is not therefore unwise. Sentences 
in codes of ethics are often quoted out without consulting context 

*° In comments on Ch^Dter 7, September 22, 2003, Gotterbam offers another explanation: 
"The assure-insure debate went principle by principle, some claiming one or the other was 
stronger, some claiming one or the other irwolved legal obligations so those principles v\Mch 
would be legally landing got the ^Dpropriate label." This explanation, though plausible in the 
abstract, does not seem to have smy basis in smy document surviving from tte period Since 
"ensure" eventually replaced "assure" everyv\tere, and transition seems to have begun after 
Langford suggested just such a conplete substitution, the mix in Version 3 seems more liMy to 
be the result of hasty drafting than of debate principle by principle, clause by clause, leaving no 
trace in the record 

* ' This inconsistency between title and text contimies in the publication of Version 3. See, 
forexanqie. Computer, November 1997: 88. 

*^ The reason we must go on the evidence is that Gotterbam no longer recalls. The only 
other possible "Bumstein" is 'Tawrence Bernstein" (at AT&T' s Bell Labs) v\tose initials are no 
closer to "C.S." than Ilene' s and the spelling of whose last name is more distant But this is not 
certain, since Gotterbam seems to have confused them now and then. In a Febmary 10, 1997 
email updating addresses, he assigns 'Tawrence Bumstein" (sic) the IIT email address: 
CSBURNSTEIN(a)HARPO.CNS.irr.EDU. By tiien, tiie Ustserv had only thirty-four names, and 
Gotterbam' s handwritten notations show an intention to drop at least six of those. 

" Gotterbam believes that both Jewett and Phillips did email comments as Version 3 was 
being prepared, but the emails do not seem to have survived either in Gotterbam' s records or 
theirs. 

** Email (Barnes to Davis), January 13, 2003: "I have no recollection of ever being involved 
in any way in this process. In view of the fact you incorrectly mailed Survive Ltd as "Survival" I 
wonder if there may be another Peter Bames in such an organization out there somewhere? 
Altematively it may be that I spoke to someone about the development of a code of practice for 
business continuity and disaster recovery planning professionals while I was at Survive. If so, I 
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have no specific recollection and doubt that I would be able to contribute in any way to your 
current research." Gotterbam (who provided the email address) thinks this is the right Peter 
Barnes: "[He] may not remember his involvement. He asked to be involved early on via email— 
his son responded saying Peter Barnes would be interested. We put Peter Barnes on the list. As I 
recall I don't think Peter Barnes ever responded to any further emails about the Code. Five years 
ago... he may not remember any of it." Whatever Barnes's contribution, it must have occurred 
very quickly. Gotterbam added Barnes to the listserv not "early on" (as in 1994 or 1995) but on 
April 11, 1997 (after trying, and failing, to do it on April 7)— and that is the last we hear of him 
(except for his inclusion in the list of Version 2.rs "authors")— or rather, the last we hear of him 
until Gotterbam and Rogerson deliberate about including him among the "authors" of Version 3 
even though he contributed nothing to it and gave no indication of wanting his name listed. His 
name remained on all subsequent versions. GotterbamWersion 2-2a-2.1\Task force vote\SRl. 
See Chapter 8 for more details. 

^^ Weclffirt, a Master of Divinity (1977), a PhD. in Philosopliy (1984), and a Diploma in 
Conpjler Science ( 1994), taught conpjter science at Charies Stuit Univensity in Wagga Wagga, 
New South Wales. He believes he first heard about the code from Gotbe±)am at a conference in 
1994 or a hat later ("work had already been going on for some time") but his name does not 
^Dpear on any list (or other document) until April 7, 1997. His only dis^Dpointment in the 
process is not having participated more. Interview with Wectert, August 9, 2001. 
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See Ch^Dber 9 for the details. 



*^ Gotteibam\by yeaA1997\feb-ap 97\Feb 97 delivered item\dfl. "Gotteibam\Hstory of SE 
Code\HistDry exparded" gives the date of the Steering Committee's contacting him about the 
"disclaimer" (cover memo) as March 14, 1997. That seems to be a mistate. April 8 seems more 
liMy since there is the email from Fiailey descrihang the Committee's request that arrived on 
that date. Gottertem had eveiy reason to work out the "disclaimer" as soon as possible, not let 
the issue hang fire for a morih vMle he worted to arrange publication of the draft And, of 
course, if we assume the earlier date, the Steering Commitbee's act would not be a quick 
response to Gotteatam' s "Status Report" (and the code that acconparded it) . 

* ^ Gotbe±iam\ty year\1997\ feb-^ 97\feb delivered item^F2. 

^ ^ Comments on Chapter 7, September 22, 2003. 

Email, MUerto Weil (Febmary 16, 2005). 
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Email, Rogerson to Davis (March 17, 2005). Rogenson describes it as an 'IEEE 
Certification of Appreciation for contributions to the development of the code of ethics for 
software engineering 1998". 
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^^ Version 2-2a-2.1\ver 2a\Hales2 (a newsy email, April 11, 1997 to Jim Hales at ETSU). 
This email also reports that, as a result of the trip, GotteriDam had become "co-director of an 
international conpjter ethics conference to be held in Rotterdam [in March 1998]." 

^ ^ Gotteri:am\by year\1997\ feb-^ 97\feb delivered item^F2. 

^ ^ Comments on Chapter 7, September 22, 2003. 

" Richard G. Epstein, The Case of the Killer Robot (New York: John Wiley and Sons, 
1996). 

^ ^ Fddman declined to be interviewed for this book because (he said) he had had nothing to 
do with writing the code. 

" GotteriDam's files include a letter that his corrpiter dates April 11, 1997 (addressed to 
"Dear Lori Claite and William Tracz") explaining the joint lEEE-CS/ACM project and asking 

SIGSOFT (the publication of the ACM's Special Interest Group on Software Engineering) to 
"publish the draft of the code for review and comment by your membership". Gotterbam 
An:hive\Version2-2a-2.1\Ver2a\SIGSOFT. 

^ ^ Apparently, Gottertem does not distinguish bdween "2a", "2.a", and "2.0a" . We shall do 
the same. 

^ ^ It is hard to see how Gottertem could have derived this idea from the minutes of April 8, 
1997. Periiaps there is a missing email. 

^° April 8, 1997. After thanking GotteriDam "for the update", the writer votes "FOR 
distribution of this code in draft form for comment, both on websites and if possitie in print" He 
then expresses his sorrow that "I am not in a position to provide [detailed commentary] in timely 
fashion" We can easily guess v\^ Gottertem would not cout this as a "response". 

^ ' Gotteri:am\by yeaA1997\organizat\FIXLST. 

^ ^ Comments on Chapter 7, September 22, 2003. 

^ ^ Unfortunately, this email is dated April 24, 1997 (and indicates the email it is responding 
to also dates from April 24). That mates no sense at all, since the essay was, by that time, at the 
printers along with the rest of the code. 

" Gotteri3am\version2-2a-2.1\delayed IHP. A SIG is a subdivision of a Working Group 
(here WG 9.2), itself a subdivision of a Technical Committee (here TC 9).The author of the file 
is Jacques Berieur (v\tose work on codes of ethics Gottertem had dted in his February 
background p^:er on codes); the conpjter date on the file is October 7, 1997, suggesting that 
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Gotterbam may not have received the document until then. This is consistent with the minutes' 
concluding paragraph: "Jacques Berleur asked members of the SIG to send him any further 
comments on the code. He offered to be in contact with Don Gotterbam and forward to him our 
observations." Apparently, not realizing how fast Gotterbam was working, Berleur took several 
months to collect comments before writing up the minutes. By then, Berleur was a veteran of the 
recently failed attempt of the IFIP to enact its own code of ethics. For very interesting details, see 
Jacques Berleur and Marie d'Udekem-Geves, "Codes of Ethics: Conduct for Computer Societies: 
The Experience of IFIP", in Technology and Ethics: A European Quest for Responsible 
Engineering, Philippe Goujon and Bertrand Heriard Dubreuil, eds. (Leuven, Belgium: Peeters, 
2000), pp.327-350. 

^^ Lite Gotbertem, the IFIP session seems to have missed (what should be) the obvious 
v\Mstle-blovving provision (under PUBLIC): "2.01 Disclose to ^Dpropriate persons or 
authorities ariy actual or potential danger that they reasonably believe to be associated with the 
software or related docunients on v\Mch they work, or are aware of, may pose to the user, athird 
party, or the environment" The label "v\Mstleblowing" seems to be inp)rtant for identifying a 
v\Mstleblowing provision Perti^:s every clause should have a teyword (rather than oriy the 
principles). 

^^ On August 7, 1997, in an email to 'Dear Task Force Member^' (and sent through the 
listserv), Gotterbam reported: "In Corfu, the International Federation of Information Processing 
Worldng Group 9 viev\oi the code [2.1] quite positively." Gotterbam could not have received the 
official minutes until two months later (October 7). He was here relying on v\tot Jacque Berieur 
and Joseph Kizz had told him (that "it received good response"). Gotterbam Ch^Dter7cmt 
(September 30, 2004). What explains the difference between the eariy favorable (oral) report and 
the later much less favorable (written) report? The most liMy explanation is that the written 
report, a summary of discussions rather than a series of votes, gave a false irrpession of the 
discussion But there are others, for exanple, that, based on other experience with the group in 
question Berieur and Kizz would consider even the written report to be positive. 

" Why Weclffirt thought "useful" had to mean only "economic value" rather than just the 
opposite of "useless" is hard to guess. What is not hard to guess is that his alternative, "not 
harmful", would mate an entirely different point Software that did not work at all might be 
useless but not harmful. 

^ ^ Comments on Chapter 7, September 22, 2003. 

" How did Naisse get a copy of Version 2.1? He was not on ariy of Gotterbam' s lists; 
Version 2.1 had not yet been published on the web. Gotterbam is not sure but notes that "once 
we had ^Dproval to publish 2.1 we were free to let others look at it" Comments on Chapter 7, 
September 22, 2003. 
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^° It also has some recent defendens. See, for exairple, Heinz C. Luegentaehl, "Themes for an 
International Code of Engineering Ethics", Proceedings of the 2003 ASEE/WFEO International 
Colloquium (American Society for Engineering Education), esp. pp. 8-9, http://www.asee.orig/ 
about/events/conferences/intemational/papers/upload/Themes-for-Int-1-Code-of-Eng-Ethics.pdf 
(September 22, 2004). 

'^ A few days later Qune 23, 1997), one of Mechler's friends (at IBM) emailed that he 
could not find www.conpjter.org and wondered v\teher Mechler had the address right Mechler 
checlffid and reported that he had just tried the address using Netsc^:e and it worl^d A few 
minutes later the friend responded "I tried another system and it worted! Mysterious conpjtens. 
I'll print it and comment Thanks." Mysterious indeed! Who said machines have driven n^^stery 
from the worid? 

' ^ Gotierbam\History of SE Code\History expanded 

' ^ Gotteri3am\History of SE Code\History expanded; and email of August 17, 2003. 
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Chapter 9: Back in the USA, Versions 

"It is impossible to make anything foolproof because fools are so ingenious." 

— Murphy's Law #11 

9.1 More comments on Version 2.1 

When Gotterbam returned to Johnson City in early July, 1997, his sabbatical officially 
over, SEEPP's prospects were much better than they had been the year before.^ When he left east 
Tennessee for his autumn semester at George Washington Urdvensity, he had all but given up 
tying to mate SEEPP work, was focusing instead on his own working group, and was having 
trouble even with them Qf the nearly forty volunteers he had reairited since eariy 1995, only a 
half dozen or so remained at all active. His co-chair was no help. SEEPP had missed several 
deadlines for producing a code and, in fact, still had nothing on p^:er but a lot of task-force 
procedures. 

That seemed a long time ago. Now Gotiedam was looking forward to official publication 
of Version 2.1 of the code (8. Appendix) and planning for Version 3 (9. Appoidix). The 
reorganized SEEPP was working v\^l. Still, the six months ahead would not be easy. The 
schedule sent the Joint Steering Committee in Febmary called for doing much before December. 
Gotterbam was supposed to have finished the ballot to survey his task force concerning the code 
ty July 4, but some work remained By August 1, he was to have developed two "ancillary 
docunients", one on "methods and techniques to support the code" and another on "special ethics 
areas". He was also supposed to have defined tte process ty v\Mch the Steering Committee 
would ultimately approve the code. (But that would have to wait until the Steering Committee 
was ready to think that far ahead) By September 1, he was to have conqieted work on both 
Version 3 and aballot for surveying software engineers v\to readtheACM's Communications or 
IEEE's Computer. There was still plenty of time for that. By October 1, the ballots were to have 
been published and returned. That date now looked unlikely. Publication schedules made 
November 15 a more reasonable deadline for return of ballots. There would then follow the 
complex but necessarily speedy revising of the code in light of the votes (and comments the 
ballot solicited), ending November 27, with a revised code (Version 3.x or perhaps 4) being 
submitted to the Steering Committee. December was to be used to revise that document taking 
into account Steering Committee comments. The final code and related documents were to be 
delivered on December 22. (By June 1998, the code was to be approved and dissemination to 
have begun! f That December 22 date for conqieling work on the "final code" was, admittedly, 
amtatious— but (given the record of the first six months of 1997) not too amtatious. 

Comments on Version 2.1 continued to come in The first of these (July 10) was from 
Walter Elden, a practicing engineer long prominent in IEEE ethics activities, v(to was writing 
other members of the IEEE Ethics-Guidelines Discussion Group (to v\Mch GotteriDam 
belonged).^ Elden suggested that the Group ("we") look at 2.1 because it "is stmctured with both 
main statements of Code Ethical Behavior [and] supporting guidelines." He asked his group to 
consider "this [as] a possible model for creating a set of Guidelines for the IEEE Code of 
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Ethics". Elden wondered whether "[this being] an activity in which an IEEE entity (Computer 
Society) is participating" 2.1 should be "coordinated with the already established and possibly 
overriding IEEE Code of Ethics" . He then told his group vAibb to find the Software Engineering 
Code on the web. * The address he gave was neither the IEEE nor the ACM website, but that of 
DeMontforts Centre for Conpjting and Social RespDnsLtality. Wliy hadn't Elden used the 
lEEE-CS site? 

The only reply to Elden' s inquiry, or at least the only one to reach Gotteibam, was sent 
eight days later ty someone with a navsea (Naval Sea Systems Command) address. It was brief: 

I reviewed the draft and have some observations: 

a The obvious one first; there is no mention of the IEEE code of Ethics. 

b. The "Product" should be the last Principle, not the first, as it is the least inpjrtant one. 

c. There is no mention of not discriminating, ebc.^ 

Coming across this email in GotteriDam's archive, I must admit to feeling sorry for both Elden 
and Gottertem Elden had asked v\teher the two codes should be coordinated. The email's 
author responded that they are not coordinated. Having thus restated the premise of Elden' s 
question), he goes on to suggest revising Version 2.1 (rather than, as Elden had asked, providing 
ideas for the IEEE Guidelines). The first revision proposed, moving Product (Principle 1) from 
first place to last, makes two dubious assumptions: 1) that the Principles are (or should be) stated 
in order of importance (instead of, say, in an order putting first what is most likely to be needed 
or— something quite different— what is logically prior); and 2) that Product is the least important 
principle (when, for example, it could be argued that it is the most important since the point of 
organizing software engineering as a profession, including writing the code, is to improve the 
products software engineers make). 

The second revision this email proposed (c) is what made me feel sorry for Gotterbam. 
While it is true (as the email says) that there is no use of the word "discriminate" (or any of its 
transforms) in any clause Version 2.1, 2.1 does require managers to act fairly (Principle 5), to 
make fair ownership agreements (5.05), and to offer fair remuneration (5.07). Principle 7 
similariy asks software engineers to treat fairly all those with whom they work (including, in 
7.07, giving a fair hearing to the opinions of others). There is even a provision (2.05) that asks 
software engineers to: "Endeavor to produce software that respects diversity. Issues of language, 
different abilities, physical access, mental access, economic advantage, and allocation of 
resources should all be considered." What more would the double negative, "not discriminate" 
(or "not discriminate unfairly") add? How is a code writer to protect against such a failure to 
look beyond formulas to meaning? 

On August 4, Langford, a member of the Task Force, responded to Version 2.1. He had 
gotten his copy from the ACM website. He had almost three pages of criticism, about equally 
divided between the Preamble and the body of the code. The criticisms were, as he said, 
generally of the "nit-picking" variety. Some just corrected typos (such as changing a capital "S" 
after a semicolon to a small "s"). Others were arguable matters of grammar (such as moving 
"fully" in 1.02 from after "to understand" to before "understand", thus splitting the infinitive, 
without any suggestion of why that might be a good idea). A few of the criticisms, when set side 
by side, suggest that even so careful (and sophisticated) a reader as Langford had trouble using 
the code. For example, Langford suggests revising 5.07 ("Offer only fair and just remuneration") 
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by deleting "only", asking "Do we need 'only'?" But he also suggests amending 4.04 ("Not 
knowingly use illegally obtained or retained software, especially on equipment of a client or 
employer or in work performed for a client or employer") by appending "— or at all". His reason 
for the addition? "This reads as though it is otherwise OK to use illegally obtained software!" 
Apparently, he is supposing that users of the code may reason that whatever 4.04 does not 
expressly forbid is permitted. Why then did he not think that "we need 'only'" in 5.07 to prevent 
the suggestion that it is OK to offer unfair and unjust remuneration to some people as long as you 
also offer fair and just remuneration to some others.^ Should not principles of inte3p:etation be 
consisbent across a single document? Should not anyone v\to has, lite Langfoid, read through 
the Preandle with enough care to catch many typos have noticed that it contains (unusually) 
detailed instmctions on how to interpret the code— instmctions that should nie out the inference 
that v\tot is not expressly foitadden is permitted (e.g., "The list of Principles and Clauses is not 

exhaustive...")? 

On August 5 (Tuesday), Gotteatam sent an urgent email to his executive committee 
("PLEASE ASAF').' The email consisted of a short covering memo followed ty "the ballot- 
survey to develop version 3" (v\Mch Gotterbam says he wants to send the Task Force "ty 
Friday"— a month behind schedule). The ballot itself consisted of another covering memo 
(addressed 'Dear Task Force Member^')/ eighteen questions (about half asking only for a "yes" 
or "no"), and the text of the code (now "2.2", after correction of typos). Several of the questions 
concerned Langf ord' s suggestions. The email asted the committee (that is. Miller and Rogerson) 
both to comment on the ballot ("and cast your vote!!") and to respond to five requests for 
suggestions about how to word ballot questions (signaled ty "**["). The first of th^ (under 
ballot question 9) is typcal: 'In 4.09.. the unless clause needs something following it Say 
'unless a higher ethical concern is being conpDmised?' Then say v\tot to do in that case? 
Confront the enployer? **[suggestions here????]" (The ballot was, when con^eted, to consist 
only of yes-or-no questions.) 

The last of Gottertem' s five requests differs from the others. Because it responds to an 
eariier query from Miller, it is inplidtly directed only to Rogerson The request (under question 
17) notes that clause 7.08 ("Not tate steps to supplant another software engineer after steps have 
been taten for enployment") is "a direct lift from engineering code", but then continues 
(^Dparenfly in Miller' s voice): "I am not sure v\tot the above item is aiming at Not to try to tate 
a job away from someone? Could the wording be made more expliciVclearer[?]" 'T)G" then 
responds in bactets: '"supplanf in Webster- to supersede, to tate the place of through 
scheming, etc." To v\Mch "KM" responds (now in bractets): "'Steps?' I don't get 7.08" 
Question 17 then continues (without kactets but in Miller^ s voice): "In 7.08, av\A?ward. Not 
tate steps?? Also the word supplant is amtaguous to me., not even sure v\tot that means here. 
Isn't 7.08 risky?? Should we interfere v\ten we see others violating the code?" Then comes the 
official request for suggestions: "this is intended to say that v\ten another person has a job 
prospect or is negotiatingajob that you won'tsteal it from them How can we fix the clause???" 

Miller's response to Gotteriiam's call for help arrived, eleven pages long, that evening. 
GotteriDam was not surprised He had come to expect from Miller responses both prorrpt and 
detailed^ Miller voted, inserting comments as he voted, and then added further comments within 
the code that followed (a code already ^Dparentiy containing eariier exchanges between him and 
GotteriDam). Miller's comments (and votes) suggest that very littie remained to be decided 
Miller voted for replacing "assure" with "ensure" buts adds "either is OK ty me". (Clearly, 
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Miller had little to do with the shift from "assure" to "ensure".) For several questions, he simply 
voted yes, correcting one typo along the way. Then he voted no on question 8, suggesting that 
4.04 might simply say, "Not knowingly use illegally obtained or retained software" (rather than, 
as the question proposed, "Not knowingly use illegal obtained or retained software, especially on 
equipment of a client or employer or in work performed for a client or employer").^ In response 
to Gotbeibam' s call for help with 4.09 (in question 9), Miller suggested adding "unless a higher 
ethical concern is being conpDmised; in that case, the enployer should be infonned of the 
engineer' s ethical concem" Having voted yes on a few more questions, conecbed another typo, 
and suggested some minor inprovements. Miller forgot about voting on the remaining questions 
and just made suggestions. Clauses 5.08 (question 14) should read, 'TSbt urgustly. . .job v\ten the 
subordinate is qualified for the job." Clause 7.02 (question 16) should read, "If another software 
engineer's work is not in the public's domain, review that work only with ^Dpropriate 
pennission, provided this is consistent with safety." Clause 7.08 (question 17) should read, 
"Don'ttry to undennine another software engineer' sjob prospects for your own personal gain" 

8.2 The v2 ballot 

By August 7 (just two days after his call for help), GotberiDam had received enough help 
to conplete the ballot Just before noon, he emailed it to the listserv— using his old George 
Washir^ton address. Why did Gotberbam not use his ETSU address? Every time Gotbedem 
moved, his email address changed Tte listserv vvould not recogrdze him at the new address until 
that address was added to the listserv's addresses (with the old one being removed to avoid 
duplicate mailings). Gotbeibam had the listserv through a friend in the Chemistry Department at 
the University of Termessee-Knoxville (DTK). When Gotbedem needed an address change, he 
notified his friend v\to, in turn, notified DTK' s Information Service. They would then tate care 
of the change v\ten other work allowed Some changes were made quickly; some took many 
weeks. (Updating Gotberbam' s listserv was not a high priority at UTK.) Luckily, Gotberbam' s 
old GWU address was both still active and still an address the listserv recognized. 

Gotberbam began his email by reporting some good news about the code's reception and 
congratulating "all" the task force for having worted "quite hard" and announced that "now I 
need two more things from you" because it "is time to develop version 3 of the Code". He then 
directed attention to the "survey [below] to solicit your oprdons about the suggested changes to 
version 2.1; noted that "we are on a tight schedule so please vote yes or no (but adding that 'If 
you don' t lite a phrase then please suggest a better one"); and explained the schedule a lit more: 

Version 3 of the Code is scheduled to be printed in IEEE Conpjber in October and the 
Communications of the ACM in November The function of the publication is to solicit 
opinions on the Code from the men±)erships of the two societies. I need a positive 
response from each of you that you want your name associated with the code aril listed 
officially in these publications as part of the task force that developed the code. If I don't 
receive a positive respjnse from you that you want your name listed [then] it wiU not be 
included in the list 

The covering memo ended with a corrqiiment "From all the comments I have received, you can 
be proud of your work on this! ! ! " 
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The ballot now had eighteen questions (followed by "v2.1ast" for both the Preamble and 
the body of the code). One question was titled "General"; the other seventeen, "Questions about 
the Principles". The general question concerned replacing "[the remaining occurrences of] the 
word 'assure' with the stronger word 'ensure'" in a) the Preamble and b) the Principles." For 
those who think ballot questions should be stated in neutral terms, this first question may seem to 
start the ballot off badly. The question had a clear bias. Those who wanted a "stronger" code 
were invited to vote yes on the general question. Those who favored uniformity but did not like 
"ensure" were given no opportunity, except comment, to change any "ensure" to "assure"; they 
could only prevent further changes from "assure" to "ensure". For those who, in addition, 
recalled the commentary on Version 2 in the triple email of February 10, just six months before 
(Chapter 7.5), the description of "ensure" as "stronger" than "assure" might have come as a 
surprise. After all, the commentary's argument for "ensure" had then been that "'ensure' is less 
legal than 'assure' which carries a formal guarantee and legal connotation (according to the 
OED); whilst 'ensure' means to strive to make things happen and no formal guarantee is 
implied."" Would not asking software engineers "to strive" for something require less than 
asking them to "guarantee" it? Had the executive committee's understanding of the meaning of 
"assure" and "ensure" changed over the six months since February (perhaps because of a visit to 
the OED)— or (as I think) was the preference for "ensure" over "assure" wholly independent of 
the reasons given, an instinct in search of a rationale? 

Though the general question seems to promise a partisan ballot, most of the other 
questions are entirely free of editorial comment. In those few that are not, the comments seem 
accurate (and, in that respect, neutral— or, at least, neutral enough). For example, question 6, 
having asked whether 2.08 ("Feel free to donate professional skills to good causes") is too 
"open-ended and non-committal", continues (correctly), "It doesn't make it seem as if there is 
any obligation in this regard." Question 6 then puts to a vote language that seems to impose an 
obligation: "Donate professional skills to good causes when opportunities arise". Since Principle 
2's "In particular" did not then limit obligations under it in any way, this change would, if 
adopted, demand quite a lot.'^ (Principle 2 read "SofbA^are engineers dhall, in their professional 
role, act only in ways consisbent with the public safely, health and welfare.") 

Within a few hours, Gotierbam had his first response (sent direct), from Tom Jewett, 
Editor of Computers and Society, the publication of ACM's Special Interest Group on 
Computers and Society (SIGCAS). Gotbeatam, v\to had known Jewett for years, was pleased, 
especially since Jewett began the response, "Delighted to be associated with this and on the 
list!!" Jewett was both someone v\to mattered in ACM and someone whom Gotierbam 
respected Jeweti:' s response showed he had given the ballot some care. He voted no on question 
1, commenting "'assure' is correct in this context [and] 'ensure' is already used v\tere 
^Dpropriate in v.2.0a." He also voted against spiitiing the infinitive in question 2 ("first version is 
grammatically correct").'* He didn't care one way or the other about the change proposed in 
question 3, endorsed the change proposed in 4 ("puts it in the correct context"), and so on— until 
te voted no on question 18 (^Dpend to 8.08 "and we must do all we can to help our colleagues 
meet these guidelines"), commenting "change is vague, and a hat reminiscent of military 
academies"). 

A second response arrived a few minutes later— from Mechler (using the listserv). Yes, 
Mechler wanted his name associated with the code. He thought it would be a good idea to use 
"titles" to "further validate the code". Hs would be "CCP" (Certified Conputer Professional). 
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He had been doing what he could to get others to respond to the Version 2 posted on various 
websites. He had scanned the code and thought that "overall" it looked helpful but he had 
several "comments". There was the usual question about "free of error" (Principle 1). "[F]or 
many systems/' he observed, "that is not a cost-effective goal." He wondered about l.Ol's "must 
have specs". For some projects, "that would be a mistake". Would it be a "mistake" because the 
clause requires that the specifications be "well documented" rather than, as in Version 1, simply 
put "in writing"? (Unless Mechler had changed his mind about the substance of the clause, that is 
the only explanation because the only other difference between Version 2.rs language and 
Version I's is the cosmetic switch from "assure" to "ensure".) Mechler had similar practical 
doubts about 1.05 "Ensure an appropriate methodology" because "most se's don't have control 
over this". (Version 2.1 had dropped Verion I's modifier "development" before "methodology". 
Was that the reason for Mechler' s objection?) Clause 1.07's "ensure realistic estimates on 
projects" raised the same question: "again, most se's don't have control over this". (Did software 
engineers have control over, as Version 1 put it, "proper cost estimates" but not, as Version 2.1 
had it, "realistic cost estimates"?)^^ Hadttevvritej:sof Veraon 2 missed siMeties in the drafting 
of Version 1? Had they made the code more demanding when they thought they were only 
clarifying v\tot was intended? Mechler concluded his prdiminaiy comments ty admitting that 
this was "the first I read the code for a v\Mle". Reading it now, he saw an omission in 8.01: "we 
seem to have left out 'analysis/iequiiements' to teep up with. We seem to have all of the life 
cycle except for the beginning." 

Mechler ended his memo indicating that he had filled in his ballot ty underiining "yes" 
or "no" (as ^Dpropriate). There was no underiining. A half hour later, Mechler emailed again: 
"My return did not have the underiine so I [am] resending leaving in my answers [that is, 
deleting "no" if he voted "yes" or deleting "yes" if he voted "no"]". Mechler voted yes on all but 
three questions. He voted against dropping "only" in 5.07, against reananging 7.02 (putting an 
"if clause" first), and against adding "and we must do all we can to help our colleagues meet 
these guidelines" to 8.08 {vMle agreeing that some such provision might be added).' ' 

Over the next few hours, five more respjnses came in— from Fairweafher, KankD, 
Fulghum, Norman, and Prinzivalli (v\to also announced the harth of a grandchild).' ^ Langford' s 
response did not arrive until August 11 (using the listserv)." Laurie Werth (UT- Austin) also 
responded that day (using the listserv), not voting but indicating, "Yes, I would lite to be 
included on the Task Force Report"— with a "ps" asking v\tether Gotteibam had "ariy ideas 
aboutaworkshop". Joyce Currie Little sent hervote in onAugust 18 (using the listserv). The last 
ballot to come in (or at least, the last we have) arrived on August 28, from me (using the 
listserv). Mine differed from the others in two ways. First, I said nothing about v\tether I wanted 
rr^^ name associated with the document (All the others had said they did) Second, I voted no on 
most questions. (Everyone else, except Werth, had voted yes on almost all questions.) The only 
questions on v\Mch I voted yes were 4 (adding "related to ariy work project" to 1.13); 6b(adding 
"and contribute to public education with respect to the discipline" in 2.08); 8 (replacing the long 
4.04 with "not knowingly use illegally obtained or retained software"); and 13 (clarifying 5.08 so 
that it would read, "Not urgustly prevent a subordinate from taking a better job v\ten the 
subordinate is qualified for tte job").^ ° 

One might conclude from so marry negative votes that I was unh^Dpy with Version 2. 
There is some tmth in that I did fed much lite the anorymous wit v\to defined a camel as "a 
horse designed ty a committee". The camel is a useful animal, at least as useful as a horse, but it 
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is not elegant (that is, beautiful to look at and a pleasure to use). What I mourned in the transition 
from Version 1 to later versions was the loss of elegance. But I also understood that a living code 
must sooner or later pass into other hands, undergo changes of which its originator would not 
approve, and become a camel. In codes, the price for permanent elegance is death. I therefore 
appreciated what Gotterbam was trying to do— fit the code to those who must use it and (above 
all) put it in a form that would cross the desert to ratification. There is even some (contemporary) 
evidence that this was my mood. About two weeks before sending my ballot in, I wrote Mechler 
(August 14, 1997): 

Your e-mail of August 8 (to Prof. Comp. Standards Task Force) reminded me that once 
upon a time you had offered to send me (on disk) all the e-mail correspondence you had 
concerning writing the code (so that I could make sure I had a complete file before I 
started writing about it). 

If that offer is still good, may I now take you up on it[?] Our work seems to be done— 
and I am itching to begin writing. 

I understood that "our work", both Mechler' s and mine, was (more or less) "done". Others were 
now in charge.^^ (Mechler responded two months later that he didn't "think our job was done 
since it [the code] is still being reviewed; maybe phase 1" but nonetheless soon sent the file.)^ ^ 

9.3 Giving credit 

While the votes were still coming in, Gotterbam found himself with another problem of 
timing. As he reported to Miller and Rogerson on August 17— in an email with the Sutgect 
"R^d respjnse needed— what else is new": "I took two days off at the end of last week and 
during that time I received a note from CACM [Communications of the ACM] editor saying that 
they are working on the November Issue of CACM and need our document NOW (implication 
being get it in now or forget it)." Gotterbam had discovered the message on Sunday and needed 
"to express mail the product [including Version 3] to her tomorrow— Monday aftemoon!!!" 
Gotterbam had attached the comments received by then (nine ballots), the vote for each question 
as it then stood (that is, minus Little's vote and mine), and as he had modified it taking into 
account both "the clearvotes [of the task force] and some of my well-founded opinions :-).' 

Having noted that "we didn't get many respjnses", Gotterbam posed a "Stupd little 
political question": 

The following did not respond: Peter Bames, British Corrpjter Society; Steve Barber 
esq., Douglas Phillips [another lawyer, one equally entitled to an "esq."], Patrick 
Sullivan, Conqxiter Ethics Institute, S. Weisband, Sec. SIGCAS [Special Interest Group 
for Conpjters and Society]. Is it politically advantageous to retain airy of these names or 
should I just delete them from the list of contributors? 

The question Gotterbam posed was not only political but ethical— and it was neither stupid nor 
little. Gotterbam' s August 7 email had explicitly said 'Tf I don't receive a positive response 
from you that you want your name listed [then] it will not be included in the list." (Italics mine.) 
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Those who had not responded to that email may have chosen not to respond because they rehed 
on Gotterbam's assurance that silence would be understood to mean, "Delete my name."^^ If any 
of them did idy on Gotbertem's words, he now had a contractual obligation to do as he said te 
would do, delete their names. His reason for not deleting their names is (he admits) "political", 
the authority he hopes to derive from their names. That hoped-for authority also raises the 
question v\^ others v\to did not vote (ty this date) are not also candidates for having their name 
deleted There were four (at this time): El-Kadi, Jayaram, Kallman, and Little. Some of these 
would have carried at least as much weight among sofbA^are engineers as, say. Barber or Phillips 
(the two lawyers). 

Having followed the ACM' s innovation of listing names after a code, Gotterbam (lite the 
ACM) had to develop criteria for choosing whom to list He in effect asked Miller and Rogerson 
for help doing that (What, beyond express consent in response to an offer, should decide v\to is 
listed?) Rogeraon's response (August 18) is disapx)irTting: "IT COSTS US NOTHING to keep 
them in and it might give us a hat of extra credir— credit to v\Mch "we" are (it seems) not 
entitled Rogerson might instead have noted the short time allowed for the ballot (a ballot that 
had not set a deadline for response), the possitality that marry of the silent may go on vacation in 
August, the unfairness of allowing mere silence (that is, periiaps, a failure of the email to reach 
its source) to count as consent, or even the inportance of early contributions to SEEPF s worlc as 
a reason to ignore a mere failure to respond^ ^ 

Of course, the sudden acceleration of the publication schedule meant that Rogerson had 
only a few hours to think through and answer a rather long memo (thirteen pages). And 
Rogerson' s life was not without its own difficulties. His response begins ty explaining that he 
would have answered sooner but his home "telephone dial [is] in crash"; he had to drive to 
canpjs to "finish this off". His response, and Gotterbam's original inquiry, nonetheless reveal a 
good deal about the drafting process.^ ^ It remains fluid and deliberative, even if rushed Though 
giving the balloting considerable weight, the executive committee clearly does not fed bound ty 
it For exanple, Gotterbam wrote that he "preferred the suggested revision of 5.05 Qewetts] 
rather than the revision actually voted on— v\tot is you[r] oprdon of the change???" To which 
Rogerson responded, "Yes me too." Gotterbam posed the same question for 5.08— except that 
there were two alternatives to the wording actually voted on Fulghum had suggested shortening 
the clause to 'TSbt urgustly prevent a subordinate from taking a better job"), vMle Norman had 
offered 'TSbt urgustly prevent a subordinate from taking a better position for v\Mch the 
subordinate is suitably qualified" Rogerson thinks: "Go with no. 2." 

Some of Gotteibam's questions require more than a choice among two or three 
alternatives. "I am," Gotterbam had written, "at a loss for 8.08" (question 18, adding "and we 
must do all we can to hdp our colleagues meet these guiddines" to "Consider violations of this 
code inconsistent with bdng a professional software engineer"). This was the only question in 
v\Mch the negatives won (3 yes's to 5 no's). Yd, there did not seem to be much hostility to the 
intention of the provision Most of those v\to voted no had offered altemative wording. 
Gotterbam wondaed v\tether Rogerson had ariy suggestions for rewording." Rogerson did 
"How about . .and encourage colleagues to adhere to this code (?at all times?)." Gotterbam had a 
similar question about 8.01: "Ed made a good comment on 8.01, unless the word 'devdopment 
is broadly constmed, we do not cover the analysis process. . . Ary suggestions for a sinqie fix." 
Rogerson responds, "How about repladng phrase with... creation testing and 
inqiementatiorii- ]or rewrite as ... further thdr knov\dedge of advances in software 
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development." Gotterbam even raised questions about provisions the ballot did not cover. "In re- 
re-reading the code/' he reports, "I got stuck at 4.05. What does '(is not inconsistent with)' mean 
in that imperative?????" Admitting that he too is unsure what 4.05 now means, he suggests 
rewording it: "4.05 Keep as confidential information gained in their professional work that is not 
in the public domain, where such confidentiality is NOT INconsistent with matters of public 
concern." ^^ 

That was Sunday. Monday afbemoon, August 18, Gotbeatam sent off Vension 3 to 
CACM. Along with the code itself went a short introductory essay ("Software Engineering Code 
of Ethics, Version 3.0") and a ballot Gotterbam, Miller, and Rogerson are listed as co-authors of 
the essay (and so, of the entire article). There were four paragr^±is and one (long footnote). The 
first paragr^±i briefly stefched the history of and purpose of the Joint Steering Committee; the 
secorid explained the three task forces; the third explained that Version 3 was the work of one of 
the task forces, SEEPP (and "reviewed by the Steering Committee for distribution and 
comment"); and the last paragraph (after reporting that the code developed out of study of the 
codes listed in the footnote) continued (in language we can now recognize as stepping over many 
hardtoseetr^Ds): 

All these codes try to educate and inspre the members of the professional group that 
adopts them Codes also inform the public about the responsihalities that are inportant in 
the profession. Codes instmct practitioners about the standard that society expects them 
to meet, and v\tot their peers strive for and expect of each other. Codes are not meant to 
encourage litigation, and they are not legislation; but they do offer practical advice about 
issues that matter to professionals and their clients and they do inform policy making. 
Based on the feedback from readers of this publication and from other sources, a final 
draft of the code will be developed and presented to the Steering Committee for approval. 

The ballot insert listed every provision of the code (except the Preamble), the Principles by 
number and tey word, the subsidiary by number and first few words (enough for identification). 
To the left of each provision were five boxes, one each under "Strongly Favor", "Favor", 
"Uncertain", "Oppose", and "Strongly Oppose".^ ^ 

The next day (August 19, 1997) Mechler emailed the listserv: 'Don, Will the Code, new 
version, stiU be on the web site?" Gotterbam responded that, vMle the new code would be on 
web sites, that would not be until "early October^' because "I don't want to put v3 on the web 
sites too much before publication, because of potential version control problems." He concluded 
by promising to send Version 3 to the task force "shortly". 

8.4 Budget ariyone? 

Since work on Version 3 was now con^ete, Gotterbam could easily meet the deadline 
for its submission to other publications (and v\^ pages). Until enough ballots had come back 
sometime in November, he could relax, that is, teach his classes and work on other projects, 
under no more pressure than an ordinary faculty member. He could even begin to thirrk about 
v\tot the Steering Commitbee should do once SEEPP had conqieted work on the code (as it was, 
according to the Febmary schedule, to do by Noven±)er 27). That, ariyway, is v\tot his 
September 5 email to Dennis FraHey seemed to say.^ ° After noting that 'life [is] easier^' (and that 
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he had recently been elected "vice chair of SIG CAS and... to chair the ACM Professional Ethics 
Committee; a committee with $0 budget"), he reported: 

We are moving along with the code. One of the common questions is how to enforce the 
code. I think a prior question is the establishment of the approval process for the code. A 
simple procedure for approval would be for the Steering Committee to approve the Code 
when it is ready and then have each of the participating societies approve it. This would 
make possible the later adoption of the same code by other professional computing 
societies like the BCS by having them also approve it.^^ 

Gotbedam was, in effect, suggesting that the Steering Commitbee follow the pnxeduie the ACM 
had used (modified to allow for the involvement of two societies instead of one). He was openly 
distancing himself from the IEEE' s Standards pnxess. 

On September 8, Fiailey replied, inserting his answers at (more or less) ^Dpropriate 
places within GotteriDam' s original. At the end of the paragraph quoted ahove, Frailey insated a 
brief (non-committal): "All ACM and IEEE codes are strictly voluntary, although the societies 
have been known to look unfavorably on people who flagrantly violate their codes." And thea in 
reply to GotteriDarri s inquiry about "accessing the travel funding you set aside for the executive 
committee to meet and work on the revisions of the code", Frailey passed a pece of news 
Gotierbam would later say hit him lite a "shock wave"^ ^ : 

The steering commitiee' s intent has been for all work to conclude this year If the code is 
not ready for recommendation by then, it will have to go in the pie of inconqiete work. I 
would reed to know how spending such funds will contribute to conqieting things ty the 
end of the year." 

Frailey later repeated the point (in answer to Gotierbam' s "What has been going on with this 
process, I have heard little about v\tere the Steering Committee is at and v\tot their plans are"): 
"The plan is to mate a set of recommendations to the societies and cease operations at the end of 
the year." The recommendations will include "doing a more conplete survey [for the Body of 
Knov\dedge] using paid staff" and "something TBD regarding education and the code of ethics". 
The "societies" (I^E-CS and ACM) would then have to decide v\tot, if aiiyfhing, to do next 
What is "really going on" is that the Steering Committee realized "that it cannot do all that must 
be done with volunteers." 

As usual, the Steering Committee's focus was the Body of Knov\dedge. It was the only 
task force that would require a "more conqiete survey" and "paid staff". SEEPP had just about 
done its work— without paid staff (and, since Febmary, more or less on schedule). Gotierbam 
had not asted for more time, only for more planning for the code beyond its ^Dproval— a request 
repeating v\tot his schedule had asted seven months before). The Steering Committee had not 
yet even thought enough about that suggestion to have any plans for 1998. Those plans were 
'TBD" (that is, to be decided la ter) . W hatever was not done by the end of the year would have to 
go into "in the pile of incomplete work". The code would have no one to be officially responsible 
for getting it through whatever process ACM and lEEE-CS would require for approval no one to 
see to its dissemination, and no one otherwise charged with helping it into practice. The code 
would be an orphan in a rough world. 
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Frailey was, however, not entirely negative. While the Joint Committee "is not planning 
to spend any more money unless it must be spent" and he (for one) is "disappointed that we have 
accomplished so little overall", he does not "wish to make matters worse". He recognizes that, 
while SEEPP "has spent the most", it has "probably done the most". So, if Gotterbam has a 
"specific reason" for wanting money before the end of the year, he should say "what it is" and 
"what we can expect from it"— with the implication that he would try to get Gotterbam the 
money. 

Gotterbam read Frailey' s observation about SEEPP spending "the most" as it was 
intended. In fact, the Body of Knowledge Task Force had spent many times what SEEPP had 
spent. But the Body of Knowledge Task Force had not spent lEEE-CS or ACM money; it paid 
for its initial survey (and for preparations for the full survey) with money from the Defense 
Department. Ethics did not have a "sugar daddy" like that— or at least SEEPP had never found 
one. So, having made that mental adjustment, Gotterbam was pleased to leam that SEEPP had 
"done the most"— despite the false starts and lack of resources. 

Two days later (September 10), Gotterbam wrote Frailey again.^'^ More than a page long, 
this email is a relatively foraial document, suggesting considerable time for its preparation 
There are three numbered sections (after the introductory, "Your response raises several 
concerns"). Together the three sections made a case for funding one face-to-face meeting of the 
executive committee. But the first section seems to have another purpose, to get Gotterbam a 
meeting with the Steering Commitiee "to finalize the critical stages of this vital project" He 
suggests around November 5-8 (v\ten the IEEE Frontiers in Engineering Education Conference 
would meet in Pittsburgh). The first section of this email also reminds Frailey that "we" 
(presumably, SEEPF s executive committee) had in February sent the Steering Committee a plan 
calling for conqieting the Code ty December "and having it recommended ty the Steering 
Committee" and that "you" had earlier said that "I would get to meet with the Steering 
Committee to discuss... future plans." The second section explains how, with "a concerted 
effort", his task force could conqiete the code and related materials "ty mid-December". He 
then asks v\ten the last meeting of the Steering Committee will be. The third section the longest, 
sums up the case for support for a (face-to-face) meeting of the executive committee: "Given the 
time constraint of the end-of-year termination of the Steering Committee it is inoperative that the 
SEEPP executive committee get together to adequately address the issues that will arise from the 
men±)ers' responses [the men±)ership polling on the Code]." Gottertem concludes: "You will 
recall that Simon Rogerson is already under pressure from his university to finalize lis visit to 
the US for this project" He does not mention the amount involved The amount Gotterbam had 
budgeted (inFebmary) was $1800 (for two meetings of the executive committee) .^^ 

We have no record of Frailey' s response, but there must have been one. Gotterbam' s 
archives contain a letter in a file dated December 7, 1997 (Sunday). It is addressed, 'Dear Dennis 
and Fdlipe [sic]" and lists expenses in two columns, one labeled "ACM" and one labeled 'TEEE- 
CS". All expenses for Rogerson are in the lEEE-CS column All expenses for Gotterbam are in 
the ACM column And those for Miller are in both columns (though with most in ACM' s). The 
letter begins ty thanking "you" for making possible a "very productive" meeting of SEEPF s 
executive committee and expressing the hope that "the final version [of the code will go] to you 
eariy next week". One wedc after Deceniier 7 would be December 14. Gotterbam was then 
telling his task force that he had a deadline of December 15 (Monday) to conqiete the code and 
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get it in to the Steering Committee. So, the file date of the letter seems very likely the date on 
which it was sent.^^ 

That letter's second paragi^ii provides evidence that Fiailey had iesp)nded to 
Gotlie±)am's eariier budgetary request (arri also explains the accounting's two columns). "You 
had," Gotberbam wrote, "expressed concern that we hall the same amount for the meeting to each 
society." In order to do that, he had "had to split Miller^s expenses". The lettjer ends with a 
suggestion that Cabrem was taking a more active role than usual in this expenditure (pedi^:s 
because it would be his last act as Steering Committee chair): "Because of your deadline Fillipe 
[sic], Rogerson has already sent in his receipts." Total expenses for the meeting were $1093.— 
But I am getting ahead of n^^ story . 

On September 23, Gotterbam received what seemed better news than Frailey's. David 
Notkia then chair of ACM's Special Interest Group for Software Engineering (SIGSOFT), 
reported that he had "forwarded tiis [the 'Action Requesf from the Steering Commitbee] to the 
SIGSOFT EC for comments."^ ' That brief message irriicated that cc' s had also gone to tte other 
two members of SEEPF s executive committee, to the chair and vice chair of the Joint Steering 
Committee (Cabrera and FraHey), to Barbacci (with no explanation), and \d Gene Hoffnagle. 
Hoffnagle, then chair of the lEEE-CS equivalent of Notkin's SIGSOFT, was Notkin's rough 
equivalent within lEEE.^^ Apparently, the Steering Committee did not want to rely entirely on 
SEEPF s ballot for evaluation of the Code of Ethics, nor did it wish again to rely on its own 
resources alone. It had therefore decided— at the conference-call meeting brought on ty 
Gotterbam' s urgent request for money (Sepben±)er 10)— to ask ^Dpropriate special interest 
groups to comment on Version 3.^ ^ 

Hoffnagle' s email to his organization's executive committee (September 24, 1997)*° 
explains the process: 

Please tate the time to review the proposed SE Code of Ethics and respond directly to the 
indicated addresses (cabrera@microsoft.com and frailey(5)dseg.ti.com) ty the deadline 
(10/15). Failure to get our comments in will betatenas ^Dproval. 

Hoffnagle then refers to one "attached note" that gives the website for the Code [Version 2.3], 
and another that "says there's an update and provides the latest version [3.0]." That attached note 
(addressed "Gene arid TCSE") contains the following instmctions: 

If reviewing this draft document, the following should be borne in mind: (1) Principles 2- 
9 are largely derived from existing Code of Ethics from other engineering disciplines[;] 
(2) We should ensure that Principle 1 in particular and the other principles as necessary 
are restricted to ethical issues. Those that are primarily technical issues in nature should 
be eliminated*' 

The instructions come from an lEEE-CS-^pointed men±)er of the Joint Steering Committee, 
Leonard Tripp, not from the Steering Committee itself. Nonetheless, they may help us to 
understand better v\tot the Steering Conmttee vvas trying to do. 

The Steering Committee seems to have leaned at least three lessons since the October 
1996 exchange between Frailey, Shaw, and Mechler (5.6). The first is that the Steering 
Committee knew a lot less about engineering ethics than they had supposed The Committee had 
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therefore decided to look for expertise elsewhere (among the leaders in software engineering). 
Second, Gotterbam's February 1997 table had demonstrated beyond doubt that Version 1— and, 
by inference, its successor, Version 3— were "largely derived from existing Codes of Ethics from 
other engineering disciplines". Tripp therefore informed the code's potential critics of that so that 
they would not repeat the errors of the previous winter. The discussion had moved on. Third, the 
code itself was no longer controversial. The focus of criticism had become those provisions some 
members of the Steering Committee regarded as "primarily technical" rather than "ethical". 

This distinction, common in (Mates about ethical codes, is seldom explained Sometimes 
the distinction seems to be a matter of detail. Detailed provisions are "technical" (and belong in a 
"code of practice") vMle general provisions are "ethical" (and can be put into a code of ethics). 
Sometimes the distinction seems to be between those provisions v\Mch are "timeless" or 
"universal" (that is, ordinary morality) and those that are relative to time and piace (much as 
laws are). Sometimes the distinction seems to be between those provisions that are (or at least 
seem liMy to be) controversial (the technical) and those that are not (the ethical). What all these 
ways of distinguishing the ethical from the technical share is the assun^Dtion that technical 
standards are never ethical standards (or ethical standards, technical)— that form or substance 
distinguish one from the other. That assun^Dtion does not seem to rely on errprical evidence. 
Marry codes of ethics, including codes of engineering ethics, are detailed and contain provisions 
that are plainly not universal, timeless, or uncontroversial. Rather than rely on a survey of actual 
codes of ethics, the assurrption seems to rely on an unexamined definition of "ethics". It is 
therefore worth pointing out that there are definitions of "ethics" that do not support that 
assun^Dtion— for exanqie, this one (explained in Chapter 1.4): those morally permissible 
standards of conduct that all rational persons in a group (at their rational best) want all the rest 
to follow even if their doing so would mean having to do the same. According to this definition, a 
code can be as detailed as can be (so long as the members of the group all want it to be), as 
relative to time and place (as members of the group want it to be), and as controversial as may be 
(because, for example, those opposed to it are not yet at their rational best).'^^ Ethics is, according 
to this definition, not so much a matter of the content of rules (^:art from moral permissihality) 
as the relation between the rules and the group they are supposed to govern Ethical standards are 
not, lite law, inpjsed on a group whatever it may want or, lite morality, handing on men±)ens of 
the group because they are moral agents bound by them whether they belong to that group or not 

9.5 Notkin responds 

Perhaps there was one more lesson that the Steering Committee had learned from the 
November 1996 debate— or its consequences. They then had before them a relatively finished 
document They might, it seemed, laveconplebedvvorkonthecodevvithinafewrnonthsif they 
had followed an ordedy procedure making small, perfecting amendments. Instead, the Steering 
Committee had inprovised Frailey and Shaw had made a great maiiy criticisms of Version 1, 
most (as it turned out) urgustified But one result of that criticism had (it seemed) been to send 
SEEPP back to the drawing board The code had become larger, more conqiex, and more 
detailed; it had, in many small ways, responded to the criticism Frailey and Shaw had made. 
(5.6) But on the v\tole, it was even less lite wtet Frailey and Shaw desired There was an irory 
in Frailey' s lament about how long the process was taking. He had written the first critique 
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himself and thereby invited Shaw to write hers; he was, it seems, the author of much of the delay 
he was now lamenting.^^ 

There is also an iroiiy in Notkin's response to the Steering Commitbee. Notkin did not 
wait for his executive committee to woric out a position He respjnded on his own on September 
26 (that is, three days after inviting his executive committee to resp)nd— and probably just three 
days after receiving the invitation to respond)/* His response, tliee pages long, begins with a 
cover memo (less than a page) addressed to "Felipe and Dennis (and Don)". After making clear 
that v\tot follows are "my own comments" (and that he hopes that those of the executive 
committee "will be forthcoming"), Notkin nonetheless claims that because some of the 
comments "are (to me at least) quite serious", he will "state clearly that until some of these 
problems are clarified and/or fixed, that ACM SIGSOFT does 'nof endorse this draft code." He 
then (disarmingly) divides his comments into "two categories": general comments "about ethics 
(such as finandd conflict) v\tere I may be especially naive"; and some about specific provisions 
v\tere "I think the code is too naive" (provisions concerned with property in softw^ or the 
software industry). Notkin is 'less worried about the first category than the second" because 
provisions in the second category are more liMy to reduce sigrdficanfly "the people that might 
pay attention to and learn from the code." He concludes this cover note by warning that his 
comments may sound "far more negative than they should" but hopes that (as a result) "they will 
generate some useful irrpovements" . 

SEEPFs executive committee seems to have taten Notkin's comments very seriously. 
GotteriDam inserted his own responses in Notkin' s email and then sent the amended document to 
the rest of the executive committee (late on September 26).* ^ Miller replied eariy Septen±)er 29 
with comments inserted at ^Dpropriate points in Notkin's document, adding his two pages to 
Notkin's original three. Gotteibam then forwarded Miller^ s comments to Rogerson with the 
instmction "Add your thoughts". Apparently, Rogerson had not yet respjnded to GotteriDam's 
first request and, indeed, did not respond even to this until a month later (October 28). The email 
that resulted from passing Notkin's comments around in this way is an exchange in v\Mch 
Notkin sounds much lite the preceeding November's Frailey-Shaw and GotberiDam-Miller- 
Rogerson often sound much lite Mechler. 

On some questions, there seems to be a profound disagreement For exanple, Notkin 
otgectstol.06: 

[Talking] about "effective procedure for promotion of quality and reduction of risk" 
[seems] reasonable, for sure. But v\tot about a situation v\tere a con^Miy (quite 
reasonably) chooses a niche in v\Mch their immediate goal is litely to be low quality but 
first on tte marl^t? Or v\tot about a conpariy that intentionally tates a high-ri^ strategy 
(perii^DS, for exanple depending on other products that aren't yet conqieted)? Pah^:s 
situations lite these are covered indirectly in the draft code, but I don' t believe that this is 
sufficient 

GotberiDam throws up his hands (figuratively): "I don't know v\tot to do here. If he is talking 
about deceiving the public, then it is not acceptable in a code of ethics. Is there a reasonable way 
to fit informed consent in here?" Miller adds that vMle risks are "unavoidable and acceptable", 
they are acceptable "ONLY v\ten the affected parties are able to choose that risk". Disclaimers 
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on risky software should be required. The bargain must be explicit. To which Rogerson can only 
respond, "I agree with Miller." 

Qn some issues, the disagreement, vMle still "serious", seems more nuanced For 
exanqie, Notkin had asserted: 

There is not a single mention of the issue of modifying or changing existing software. 
Since this is a pece of the industry, the omission is obvious and serious. I don't believe 
that adding in a few vvoids can haiifle this easily. . .because in niany cases the pressures to 
mate changes without a "full" understanding of the software are rml and reasonable. 

For Notkin, the atality to "change and evolve software is one of the primary characteristics that 
distinguishes software from other engineering disciplines." If the code says nothing helpful about 
how to change existing software, "we can use 'ariy old engineering code of ethics' ." Apparently, 
Notkin, a conpjter scientist, does not know that engineers generally examine the systems on 
v\Mch they work, looking for ways to inpDve them, and regulariy do mate irrpovements. (In 
fact, one way to distinguish between engineers and technicians (or, rather, "mere technicians") is 
that engineers are supposed to irrpove what they work on vMle technicians are merely 
supposed to teep v\tot they work on as designed)* ' Notkin does nonetheless raise an inp^rtant 
question: v\^ not just use an engineering code (a good one, not "ariy old one"); v\^ write yet 
another code? The answer to that question would seem to be in (v\tot was then) Principle 1, 
those provisions concerned in particular with "product". 

That engineers might "change and evolve" their products also seems not to have occuned 
to the three conpjter scientists constituting SEEPFs executive committee. Instead, they follow 
Notkin in thinking about the question as one peculiar to software engineering. Miller wondered 
v\tether it "is 'reasonable' to mate changes in code without a full understanding of the 
software???" Miller did not think it "reasonable or ethical" to change software without an 
adequate understanding of the consequences. GotteriDam agreed with Notkin that "modifyahality 
is one of the distinguishing characteristics" but not with the conclusion Notkin drew from it: 
"v\ten we teach maintenance we say that the normal development process is ^Dplied to an 
existing software artifact— understand the needed change, design the change, inplement and test 
the change[,] and mate sure that the change ha[s] no unexpected side effects." Rogerson thought 
there might be a middle way: "Peih^Ds the issue is [v\teher] to undertate appropriate inpact 
analysis prior to software modifications taking into account the rol^ functionality of the 
software— the greater scope wrt [with respect to] people, organizations, society[,] the more care 
required My ethical hotspot concept!" 

Now and then, SEEPFs executive committee singly recognizes the merit of Notkin' s 
comment For exanqie, Notkin observed that "1.14 talks about making tradeoff's visible to all 
parties concerned, including the public. . .[and] 6.13 talks about sharing 'useful software-related 
knov\dedge, inventions, or discoveries with the profession' ." The draft does not, however, "mate 
it clear that conpardes and software engineers have interests— in particular, certain classes of 
intellectual property— that needn't be disclosed, or that must be disclosed with care." Notkin 
recogrrized that the code does "address this somev\tot in Principle 4, especially 4.05 ['Keep as 
confidential information gained in their professional work that is not in tte public domain, v\tere 
such confidentiality is not inconsistent with matters of public concern' ], btrt; explicitly observing 
this inherent set of conflicts seems of value." Gotterbam's response to Notkin hae is, "Ary 
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suggestions for rewording." To this, Miller gives the opinion that it "seems doable with a few 
words" and then expresses "trust in your pen, Don." Rogerson adds: "guess we can fix this in 
Dec! !" (when they are to meet in person to revise the Code). 

One set of comments is interesting simply for what it tells about how SEEPP's executive 
committee worked. Notkin objected to 6.07 ("only accept remuneration appropriate to 
professional qualifications or experience") that many of the top hundred richest people in 
technology "got rich essentially as software engineers who started companies." Notkin does not 
want to have to argue about whether they "accepted appropriate remuneration". Gotterbam's 
response is surprisingly sympathetic. After observing that "[pointing] to the existence of robber 
barons to show that an imperative doesn't belong in a code does not seem reasonable", he admits 
that he "always had trouble with this clause." When he consulted, his price was "in part based on 
the criticality of the project and which elements of my talents are employed." He did accounting 
packages "at a cheap rate" but nuclear reactor development at a higher rate. "Same guy, but 
different talents are required." He then asked what the others thought. Miller is brief (and not his 
usually perceptive self): "Maybe we should make this more explicit: 'Never take inflated wages 
when you know it is a bribe." (If this interpretation were right, 6.07 would belong under 
Principle 3 JUDGMENT, not under Principle 6 PROFESSION, and would be redundant in 3.) 
Rogerson deepens the problem Gotterbam had identified: 

I am reminded of my time in Poland when my Polish colleagues could not afford latest 
proprietary software because of global pricing policies from MS and the like designed to 
maximize profit and minimize administrative effort regardless of social/economic impact 
in developing countries. This is a difficult clause but I don't think its just about bribes[— ] 
it is about social justice. A code should set the moral high ground for us to aspire to. 
Somehow we have to write a clause that does this but takes the RB [robber baron] 
supporters with us. December's "toughie" task!!! 

That task was of their own making. In Version 1, the corresponding provision (5.07) was 
much more limited: "Only accept a salary appropriate to professional qualifications." That 
language had survived more than half a century in several engineering codes. The executive 
committee had substituted "remuneration" for "salary"— without explanation but apparently with 
the intention of extending the provision to consultants.'^^ They Imew nothing of the clause's 
hisboiy, that is, that it was intended primarily to teep engineers from accepting salaries 
inappropriate to (that is, below) their qualificatiorL There was no risk of enqioyers paying too 
much. The inequalities of the marl^t saw to that (since engineers are supposed to be candid in 
ariy statement of qualifications) ! ^ Having inflated a worlsable provision into an unworkable one, 
SEEPF s executive committee would soon (Version 4) delete it altogether.^ ° 

While Gottertem, Miller, and Rogerson in this exchange with Notkin often sound lite 
Mechler responding to Frailey and Shaw, Gotterbam, Miller, and Rogerson did not mate the 
mistate Mechler had They did not send these first inp:essions to Notkin or the Steering 
Committee. Instead, they (that is, GotteriDam with the assistance of Miller and Rogerson) 
carefully prepared a more diplomatic response about as long as Notkin' s original email. The 
response seems not to have been sent until Decen±)er 3. It began 'T)ear David (Dennis, Felipe)" 
and ended "Sincerely, Don Gottertem.". ^ ' After thanking Notkin "for your careful evaluation of 
the draft Software Engineering Code of Ethics v3.0", Gottertem ^x)logized for taking so long to 
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respond, but he wanted "to clear my response to your concerns with the rest of the [executive] 
committee that has been working on the code." He also let Notkin know that there have been 
other responses as a result of publishing the code and "our responses to your comments 
incorporate responses to other comments on the Code."^^ 

The prdiminaries over, Gotbeibam begins the substantive discussion: "You are right that 
we did not specifically mention maintenance". The commitbee did not intend any disrespect; it 
merely viev\^ maintenance as "another type of development". The commitbee nonetheless 
understood v\tot was bothering Notkin, "the unfortunate circumstance you alluded to v\tere 
some developers treat maintenance as a mindless exercise". That is an attitude the code should 
not, by silence, encourage. Gotberbam therefore proposed to add new language to the Preamble 
"explicitly" mentioning maintenance (quoting two new sentences) and to revise 8.01 in much the 
same way. 8.01 would then read: 'Tuither their knov\dedge of developments in the design, 
devdoprnent, maintenance, and testing of software and related documents, together with the 
management of the development process." 

Having given Notldn everything he could have wished on one point (almost a page and a 
half of you-are-right-about-maintenance), Gotterbam tates up Notkiri s next point, sounding as if 
he is again going to give Notkin everything he wants: "Your second comment about 'shrink 
wrapped software' development for the martet, rather than development for a specific client[,] 
was right on the mark" Gotterbam then announced that "we" are going to "stipulate a 'client for 
shrink wr^Dped software: the person or persons v\to must be satisfied before the product is 
shipped" (Whether this stipulation is for purposes of discussion here or a change in the code 
itself is not clear.) Having defined his terms, he noted a "concern that a shrink wrapped client 
[sic] may agree to software that is damaging in some way to some users". Risks are, of course, 
"unavoidable and acceptable" but "only v\ten the affected parties are able to choose that risk". 
There should therefore be disclaimers on the software. "Contractual bargains must be explicit" 

Then, without even a new paragraph, Gotterbam moved on to Notkiri s "third point about 
those v\to 'choose a niche in v\Mch their immediate goal is to produce a software product that is 
liMy to be low quality but first on the martet" Tradeoffs will have to be made, tut (Gotterbam 
added) "the professional is obliged to mate these clear. Look at the reaction to the Intel Pentium 
[clip] fiasco [bugs Intel knew about but did not reveal until the public discovered them on its 
own]."^ ^ Clause 1.14 ("promote maximum safety") will stay as it is. 

Gotterbam then returned to his accomnxxlating tone. He agreed that Notkin is right that 
6. 13 ( "Share useful software-related knov\dedge. . . ) should be revised to respect the "rights of the 
third parties and confidentiality".^* There should (he added) also be a cross reference to 4.05 
("Keep as confidential..."). Gotterbam took a similar tack with 1.15 (after admitting, "We 
struggled with this"). 1.15 should be changed to (uppercase indicating the additions): "Work to 
follow SUFFICIENT industry standards WHEN AVAILABLE that are most ^Dpropriabe to the 
task at hand...)". The word "sufficient' suggests that "there are several acceptable 
methodologies" and "v\ten available" that there may be "no best method" for certain projects.^ ^ 
Clause 3.07 ("Refuse to participate in any decision of a governmental body... .in which they, 
their employer, or their client has a financial interest") should be deleted because, as other 
commentators had also pointed out: the clause is too "absolute" .^^ Its concern, however, is 
reasonable and already covered in 3.06 ("Disclose to all concerned parties those conflicts of 
interest that cannot reasonably be avoided or esc^:ed and aspie to resolve them"). FrnaUy, there 
is Clause 6.07 ("Only accept remuneration ^Dpropriate. . ."). It would, Gotterbam explains, have 
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been better stated as "never take inflated wages when you know it is a bribe." Apparently, that 
clause is to be revised accordingly. 

Gotterbam then concluded by observing how "very few comments [were received] from 
publication of [Version 2.1] in SIGSOFT this summer", but now "we are... getting a good 
representative sample [in response to publication of Version 3.0]". Like any "good software 
engineering project more reviews improve the quality of the product." SEEPP's executive 
committee will be meeting soon to "put the finishing touches on the Code". The committee 
"would appreciate further comments" from Notkin. Neither Notkin himself nor the SIGSOFT 
executive committee commented again on Version 3.^^ But, as Gotbertem had told Notkin, he 
had by then a good many comments from othens— and, as he not not tdl Notkin, they seldom 
seemed concerned with vitet concerned him 

9.6 On to Version 4 

One of the first comments to arrive after Nodkin's, though addressed to "Gene and 
Leonard", was a forward from Laurie Werth. Apparently, the author of the comment, "Cari", was 
a member of the TCSE, the IEEE equivalent of Notkin' s SIGSOFT. In other respects, however, 
the respjnse was quite different Tte tone was, as Gotterbam noted v\ten (on October 14) he 
passed it on to Miller and Rogerson, "better. . . than the one from Notkin (ACM)."^ ^ Cari began 
by "[agreeing] with Leonard that these principles look very familiar." Cari had taught corrpjter 
ethics in a "CS program (2 hours, required course)". The code "is a very good integration of all 
ethical principles." His chief "trouble in reading [the code]" is "the so-called three-level 
classification of clauses: Aspre, Expect and Demand" He cannot "tell (with ease) v\Mch is 
which." For exanple. Clause 3.03 says 'Tlgect bribery". Is this an aspration, an expectation, or 
a derrMid? "It vvould" he suggests (in a tone suggesting to nie that he doubts that it can be done), 
"be a good service to us (educators) to label each clause one of the three levels if our dear 
authors can sort them out cleariy." He then adds, "There are still some typos I guess" and 
concludes that he is "excited about seeing [the code] and would love to use it in my course." 
That was the last Gotterbam heard from the TCSE. 

For the Steering Committee, that silence would, presumably, count as support for the 
code (just as the silence of Notkin' s executive committee should). So, Version 3 had, ty 
December, passed one test The organizational critics of 3.0 had been few, in fact far fewer thai 
Gotterbam had expected And only one of them, Notkin, had made any serious criticism of the 
code itself— and even his were limited to a few clauses that could easily be revised The 
question, thea vvas: v\tot would the ballots show? By December 3, v\ten Gotterbam sent off his 
response to Notkin, the answer to that question was clean the changes the code required would 
be more than a change in the version's decimal numbering could accommodate. There would be 
a Version 4.0. 
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9. Appendix (Version 3): 

S(tfh\ere Engineeriiig Code of Ethics 

lEEE-CS/ACM Jcint Ta^ Fcroe en SoAware En^ueering Ethics and Profesacnal 
Practices 

Don Gotterbarn, Keith Miller, Simon Rogerson 



In May of 1993, the Board of Governors of the lEEE-CS established a Steering Committee for 
evaluating, planning, and coordinating actions related to establishing software engineering as a 
profession. In that same year the ACM Council endorsed the establishment of a Commission on 
Software Engineering. By January of 1994, both societies formed a joint steering committee "To 
establish the appropriate set(s) of standards for professional practice of Software Engineering 
upon which industrial decisions, professional certification, and educational curricula can be 
based." To accomplish these tasks they made the following recommendations: 

1. adopt standard definitions, 

2. define required body of knowledge and recommended practices 

3. define ethical standards 

4. define educational curricula for undergraduate, graduate(MS) 
and continuing education (for retraining and migration). 

The Steering Committee decided to accomplish these tasks through the establishment of a series 
of task forces. Initially the task forces established were: Software Engineering body of 
knowledge and recommended practices; Software Engineering ethics and professional practices, 
and Software Engineering curriculum. 

The purpose of the Software Engineering ethics and professional practices task force is to 
document the ethical and professional responsibilities and obligations of software engineers. This 
draft code of ethics was developed by a task force of the Joint IEEE Computer Society and 
Association for Computing Machinery Steering Committee for the Establishment of Software 
Engineering as a Profession. The task force on Software Engineering Ethics and Professional 
Practices developed this code for a sub-specialization within the constituencies of both of the 
professional societies. In an attempt to reflect the international character of both organizations 
and the profession as a whole, the composition of the task force is multinational in both 
citizenship and in membership in professional computing organizations. The proposed draft 
Code of Ethics for Software Engineers (version 3) was developed by the task force and reviewed 
by the Steering Committee for distribution and comment. The purpose of this distribution is to 
solicit comments from practitioners and other interested parties. 

Codes, if carefully written and properly promoted, can be powerful instruments in the drive for 
Professionalism and in establishing safeguards for society. They do not have to be and should not 
be sterile which is often the perception that people have of them. This draft code evolved after 
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extensive study of several computing and engineering codes[l]. All these codes try to educate 
and inspire the members of the professional group that adopts the code. Codes also inform the 
public about the responsibilities that are important to a profession. Codes instruct practitioners 
about the standards that society expects them to meet and what their peers strive for and expect 
of each other. Codes are not meant to encourage litigation, and they are not legislation; but they 
do offer practical advice about issues that matter to professionals and their clients and they do 
inform policy makers. These concepts have been adopted in the development of this code. Based 
on the feedback from readers of this publication and from other sources, a final draft of the code 
will be developed and presented to the Steering Committee for approval. 



[1] Codes refered to include: The American Association of Engineering Societies, Model Guide 
for Professional Conduct; Accreditation Board for Engineering Technology's, Code of Ethics for 
Engineers and Guidelines for The Fundamental Cannon of Ethics; The Association of 
Computing Machinery's Code of Ethics and Guidelines for Professional Conduct, The British 
Computer Society, Code of Conduct; The British Computer Society, Code of Practice; The 
Institute for the Certification of Computing Professionals; The Engineer's Council for 
Professional Development; Faith of the Engineer; The Institute of Electronical and Electronics 
Engineers, Code of Ethics; The National Society of Professional Engineers, Code of Ethics for 
Engineers, and the Project Management Institute Code of Ethics for the Project Management 
Profession. 



PREAMBLE 



Computers now have a central and growing role in commerce, industry, government, medicine, 
education, entertainment, social affairs, and ordinary life. Those who contribute, by direct 
participation or by teaching, to the design and development of software systems have significant 
opportunities both to do good or to cause harm, and to influence and enable others to do good or 
cause harm, To ensure, as much as possible, that this power will be used for good, software 
engineers must commit themselves to making the design and development of software a 
beneficial and respected profession. In accordance with that commitment, software engineers 
shall adhere to the following Code of Ethics. 

The Code contains eight Principles related to the behavior of and decisions made by professional 
software engineers, be they practitioners, educators, managers and supervisors, or policy makers, 
as well as trainees and students of the profession. The Principles identify the various 
relationships in which individuals, groups, and organizations participate and the primary 
obligations within these relationships. 

Each Principle of this code addresses three levels of ethical obligation owed by professional 
software engineers in each of these relationships. The first level identified is a set of ethical 
values, which professional software engineers share with all other human beings by virtue of 
their humanity. The second level obliges software engineering professionals to more challenging 
obhgations than those reguired at level one. Level two obligations are reguired because 
professionals owe special care to people affected by their work. The third and deeper level 
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comprises several obligations which derive directly from elements unique to the professional 
practice of software engineering. The Clauses of each Principle are illustrations of the various 
levels of obligation included in that relationship. 

The Clauses under each Principle consist of three different types of statement corresponding to 
each level. Level One: Aspire (to be human); statements of aspiration provide vision and 
objectives and are intended to direct professional behavior. These directives require significant 
ethical judgement. Level Two: Expect (to be professional); statements of expectation express the 
obligations of all professionals and professional attitudes. Again, they do not describe the 
specific behavior details, but they cleariy indicate professional responsibilities in computing. 
Level Three: Demand (to use good practices); statements of demand assert more specific 
behavioral responsibilities within software engineering, which are more closely related to the 
current state of the art. The range of statements is from the more general aspirational statement to 
specific measurable requirements. 

Although all three levels of professional obligation are recognized, the Code is not intended to be 
all inclusive, nor is it intended that its individual parts be used in isolation to justify errors of 
omission or commission. The list of Principles and Clauses is not exhaustive, and should not be 
read as separating the acceptable from the unacceptable in professional conduct in all practical 
situations. The Code is not a simple ethical algorithm which generates ethical decisions. In some 
situations standards may conflict with each other or with standards from other sources. These 
situations require the software engineer to use ethical judgement to act in a manner which is most 
consistent with the spirit of the Code of Ethics, given the circumstances. 

These ethical tensions can best be addressed by thoughtful consideration of fundamental 
principles, rather than reliance on detailed regulations. These Principles should influence you to 
consider broadly who is affected by your work; to examine if you and your colleagues are 
treating other human beings with due respect; to speculate on how the public would view your 
decision if they were reasonably well informed; to analyze how the least empowered will be 
affected by your decision; and to consider whether your acts would be judged worthy of the ideal 
professional working as a software engineer. Since this code represents a consensus of those 
engaged in the profession one should take into account what is likely to be judged as the most 
ethical way to act in the circumstances by informed, respected, and experienced peers in 
possession of all the facts and only depart from such a course for profound reasons, backed with 
careful judgement. 

The dynamic and demanding context of software engineering requires a code that is adaptable 
and relevant to new situations as they occur. However, even in this generality, the code provides 
support for the software engineer who needs to take positive action by documenting the ethical 
stance of the profession; it provides an ethical foundation to which individuals within teams and 
the team as a whole can appeal. The code also helps to define those things which are ethically 
improper to request of an software engineer. 

The code has an educational function, stating what is required of anyone wishing to join or 
continue in the software engineering community. Because it expresses the consensus of the 
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profession on ethical issues, it can be used as a guide to decision making and as means to educate 
both the pubhc and aspiring professionals about the professional obligation of all software 
engineers. 



PRINCIPLES 

PdudpAe 1: PRODUCT. Software engineers shall, insofar as possible, ensure that the software 
on which they work is useful and of acceptable quality to the public, the employer, the client, and 
the user; completed on time and at reasonable cost; and free of error. In particular, software 
engineers shall, as appropriate: 



1.01. Ensure that specifications for software on which they work have been well documented, 
satisfy the user's requirements, and have the client's approval. 

02. Strive to fully understand the specifications for software on which they work. 

03. Ensure that they are qualified, by an appropriate combination of education and 
experience, for any project on which they work or propose to work. 

04. Ensure proper and achievable goals and objectives for any project on which they work or 
propose. 

05. Ensure an appropriate methodology for any project on which they work or propose to 
work. 

06. Ensure good management for any project on which they work, including effective 
procedures for promotion of quality and reduction of risk. 

07. Ensure realistic estimates of cost, scheduling, personnel, and outcome on any project on 
which they work or propose to work and provide a risk assessment of these estimates. 

08. Ensure adequate documentation on any project on which they work, including a log of 
problems discovered and solutions adopted. 

09. Ensure adequate testing, debugging, and review of software and related documents on 
which they work. 

10. Work to develop software and related documents that respect the privacy of those who 
will be subjected to that software. 

11. Be careful to use only accurate data derived from legal sources, and use only in ways 
properly authorized. 

12. W henever appropriate, delete outdated or flawed data 

13. Work to identify, define and address ethical, economic, cultural, legal, and environmental 
issues related to any work project. 

14. Promote maximum quality and minimum cost to the employer, the client, the user and the 
public. Make any tradeoffs clear to all parties concerned. 

15. Work to follow industry standards that are most appropriate for the task at hand, 
departing from these only when technically justified. 



Priiici[d.e 2: PUBLIC Software engineers shall, in their professional role, act only in ways 
consistent with the public safety, health and welfare. In particular, software engineers shall: 
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2.01. Disclose to appropriate persons or authorities any actual or potential danger to the user, a 
third party, or the environment, that they reasonably believe to be associated with 
software or related documents for which they are responsible, or merely know about. 

2.02. Approve software only if they have a well-founded belief that it is safe, meets 
specifications, has passed appropriate tests, and does not diminish quality of life or harm 
the environment. 

2.03. Affix their signature only to documents prepared under their supervision or within their 
areas of competence and with which they are in agreement. 

2.04. Co-operate in efforts to address matters of grave public concern caused by software or 
related documents. 

2.05. Endeavor to produce software that respects diversity. Issues of language, different 
abilities, physical access, mental access, economic advantage, and allocation of resources 
should all be considered. 

2.06. Be fair and truthful in all statements, particulariy public ones, concerning software or 
related documents. 

2.07. Not put self-interest, the interest of an employer, the interest of a client, or the interest of 
the user ahead of the public's interest. 

2.08. Donate professional skills to good causes when opportunities arise and contribute to 
public education with respect to the discipline. 

2.09. Accept full responsibility for their own work. 



PdndpAe 3: JUDGMENT Software engineers shall, insofar as possible and consistent with 
Principle 2, protect both the independence of their professional judgment and their reputation for 
such judgment. In particular, software engineers shall, as appropriate: 

3.01. Maintain professional objectivity with respect to any software or related documents they 

are asked to evaluate. 
3.02 Affix their signature only to documents prepared under their supervision and within their 

areas of competence. 

3.03. Reject bribery. 

3.04. Accept no payback, kickback, or other payment from a third party to a contract, except 
with the knowledge and consent of all parties to the contract. 

3.05. Accept payment from only one party for any particular project, or for services specific to 
that project, except when the circumstances have been fully disclosed to parties 
concerned and they have given their informed consent. 

3.06. Disclose to all concerned parties those conflicts of interest that cannot reasonably be 
avoided or escaped and aspire to resolve them. 

3.07. Refuse to participate in any decision of a governmental or professional body, as a 
member or advisor, concerned with software, or related documents, in which they, their 
employer, or their client have a financial interest. 

3.08. Temper all technical judgements by the need to support and maintain human values. 
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PRINCIPLE 4: CLIENT AND EMPLOYER Software engineers shall consistent with the 
pubhc health, safety, and welfare, always act in professional matters as faithful agents and 
trustees of their client or employer. In particular, software engineers shall: 

4.01 . Provide service only in areas of their competence. 

4.02. Ensure that any document upon which they rely has been approved by someone 
authorized to approve it. 

4.03. Use the property of a client or employer only in ways properly authorized, and with the 
client's or employer's knowledge and consent. 

4.04. Not knowingly use illegally obtained or retained software. 

4.05. Keep as confidential information gained in their professional work that is not in the 
public domain, where such confidentiality is not inconsistent with matters of public 
concern. 

4.06. Identify, document, and report to the employer or the client any problems or matters of 
social concern in the software or related documents on which they work or of which they 
are aware. 

4.07. Inform the client or the employer promptly if, in their opinion, a project is likely to fail, 
to prove too expensive, to violate intellectual property legislation, in particular copyright, 
patent, and trademarks, or otherwise be problematic. 

4.08. Accept no outside work detrimental to the work they perform for their primary employer. 

4.09. Represent no interest adverse to their employer's without the employer's specific consent , 
unless a higher ethical concern is being compromised; then in that case the employer or 
another appropriate authority should be informed of the engineer's ethical concern. 



Piiiidpl.e 5 MANAGEMENT. A software engineer in a management or leadership capacity 
shall act fairly and shall enable and encourage those who they lead to meet their own and 
collective obligations, including those under this code. In particular, those software engineers in 
leadership roles shall as appropriate: 

5.01 . Ensure that employees are informed of standards before being held to them. 

5.02. Ensure that employees know the employer's policies and procedures for protecting 
passwords, files, and other confidential information. 

5.03. Assign work only after taking into account appropriate contributions of education and 
experience tempered with a desire to further that education and experience. 

5.04. Provide for due process in hearing charges of violation of an employer's policy or of this 
code. 

5.05. Develop a fair agreement concerning ownership of any software, processes, research, 
writing, or other intellectual property to which an employee has contributed. 

5.06. Attract employees only by full and accurate description of the conditions of employment. 

5.07. Offer fair and just remuneration. 

5.08. Not unjustly prevent a subordinate from taking a better position for which the subordinate 
is suitably qualified. 

5.09. Not ask an employee to do anything inconsistent with this code. 
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Pdiici[d.e6c PROFESSION. Software engineers shall, in all professional matters, advance both 
the integrity and reputation of their profession as is consistent with public health, safety, and 
welfare. In particular, software engineers shall, insofar as possible: 

6.01 . Associate only with reputable businesses and organizations. 

6.02. Ensure that clients, employers, and supervisors know of the software engineer's 
commitment to this code of ethics, and their own responsibility under it. 

6.03. Support those who similarly do as this code requires. 

6.04. Help develop an organizational environment favorable to acting ethically. 

6.05. Report anything reasonably believed to be a violation of this code to appropriate 
authorities. 

6.06. Take responsibility for detecting, correcting, and reporting errors in software and 
associated documents on which they work. 

6.07. Only accept remuneration appropriate to professional qualifications or experience. 

6.08. Be accurate in stating the characteristics of software on which they work, avoiding not 
only false claims but claims that might reasonably be supposed to be deceptive, 
misleading, or doubtful. 

6.09. Not promote their own interest at the expense of the profession. 

6.10. Obey all laws governing their work, insofar as such obedience is consistent with the 
public health, safety, and welfare. 

6.11. Exercise professional responsibility to society by constructively serving in civic affairs. 

6.12. Promote public knowledge of software engineering. 

6.13. Share useful software- related knowledge, inventions, or discoveries with the profession, 
for example, by presenting papers at professional meetings, by publishing articles in the 
technical press, and by serving on the profession's standard- setting bodies. 



Piiiici[d.e 7: COLLEAGUES. Software engineers shall treat all those with whom they work 
fairly and take positive steps to support coUegial activities. In particular, software engineers 
shall, as appropriate: 

7.01. Assist colleagues in professional development. 

7.02. Review the work of other software engineers, which is not in the public domain, only 
with their prior knowledge, provided this is consistent with public health, safety, and 
welfare. 

7.03. Credit fully the work of others. 

7.04. Review the work of others in an objective, candid, and properly- documented way. 

7.05. Give a fair hearing to the opinion, concern, or complaint of a colleague. 

7.06. Assist colleagues in being fully aware of current standard work practices including 
policies and procedures for protecting passwords, files, security measures in general, and 
other confidential information. 

7.07. Not interfere in the professional career progression of any colleague. 

7.08. Not undermine another software engineer's job prospects for one's own personal gain. 
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7.09. In situations outside of their own areas of competence, call upon the opinions of other 
professionals who have competence in that area. 



Pdiici[d.e a SELF. Software engineers shall, throughout their career, strive to enhance their 
own ability to practice their profession as it should be practiced. In particular, software engineers 
shall continually endeavor to: 

8.01. Further their knowledge of developments in the analysis, design, development, and 
testing of software and related documents, together with the management of the 
development process. 

8.02. Improve their ability to create safe, reliable, and useful quality software at reasonable 
cost and within a reasonable time. 

8.03. Improve their ability to write accurate, informative, and literate documents in support of 
software on which they work. 

8.04. Improve their understanding of the software and related documents on which they work 
and of the environment in which they will be used. 

8.05. Improve their knowledge of the law governing the software and related documents on 
which they work. 

8.06. Improve their knowledge of this code, its interpretation, and its application to their work. 

8.07. Refrain from requiring or influencing others to undertake any action which involves a 
breach of this code. 

8.08. Consider violations of this code inconsistent with being a professional software engineer 
and encourage colleagues to adhere to this code. 



This draft Code was developed by the lEEE-CS/ACM joint task force on Software Engineering 
Ethics and Professional Practices: 

Chair: Donald Gotterbam; 

Executive Committee: Keith Miller and Simon Rogerson; 

Members: Peter Barnes, Steve Barber esq., Ilene Bumstein, Amr El-Kadi, N. Ben 
Fairweather, Milton Fulghum, N. Jayaram, Tom Jewett, Maj. Mark Kanko, Ernie 
Kallman, Duncan Langford, Joyce Currie Little, Ed Mechler, Manuel J. Norman, 
Douglas Phillips, Peter Ron Prinzivalli, Patrick Sullivan, John Weckert, S. Weisband, and 
Laurie Honour Werth, 



262 



Notes 

^ Gotte±)am does not recall the exact date of his return to Johnson City. What he does 

recall is that his wife left about two weeks before he did (in late June) because of the death of her 
mother. Gotterbam followed "early in July". Email September 18, 2003 (RE: ch. 7). What we do 
know is consistent with v\tot he recalls. On July 21, Ben Fairweather forwarded two emails sent 
to Gotterbam' s DeMontfort address. The earlier of these is dated July 10, suggesting a departure 
before then GotterbamWersion IXCODECOMMENT. 

^ Gotterbam\Steering Committee\Schedule\SchedV2 (Febmary 13, 1997). 

^ Elden was about to retire from the Harris Corporation after a forty-six year career in 

engineering (electronics, tdemeby, data acquisition, communications, and networking). For a 
summary of his career, see: http://onlineethics.org/haos/eldenhtml. 

^ GotterbamWersion IVCODECOMMENT. Why might Elden think that the IEEE code 

could override the Software Engineering Code? That is not clear. The IEEE code ^Dplies only to 
IEEE members (not to electrical and electronic engineers as such); it is therefore the code of 
ethics of a technical society, not of a profession. The Software Engineering Code ^Dplies to 
software engineers (and ordy to them), whether or not members of the IEEE; that is, it is a 
professional code (that is, a code governing members of the profession as such). Should the two 
codes conflict (something unlikely given the generality of the IEEE code), a software engineer 
would have to choose between his profession and remaining a member in good standing of the 
IEEE. But there is no reason why any profession should give priority to the code of ethics of a 
technical society to which its members belong, especially one in which its members are a 
minority (as software engineers were— and are— within the IEEE). 

^ GotterbamWersion IVCODECOMMENT. 

^ Their reasoning would be (in effect): I follow the code because I follow it sometimes. 

The fallacy is obvious: to say you follow the code sometimes (but not all the time) is to say you 
violate the code sometimes (but not all the time) . One does not have to violate a code often to act 
unethically. Indeed, one only has to violate it once. 

^ GotterbamWersion 2- 2a- 2. l\Taskforcevote^allot 

^ Gotterbam Ch^DScmt (September 28, 2004). 

^ When drafting Version 1, I tried to limit the obligations of software engineers to what 

they do as software engineers (primarily on the job, but also in public acts where they would be 
so identified). A professional code is, I believe, not a code for a whole life, but only for the 
professional part of it. One general direction of change from Version 1 to Version 3 is to restate 
obligations so that they restrict what software engineers do as private citizens in off-duty hours 
(as well as what they do when acting as software engineers). The proposed revision of 4.04 fits 
this pattern. Why then did I vote for the proposed revision (the one Langford suggested 
shortening)? Simply because the shorter clause was shorter— without loss of content. I was not 
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given the option of returning 4.04 to its original form: "Not knowingly use pirated software on 
equipment of a client or employer or in work performed for a client or employer." I would, 
however, have been happy to replace "pirated software" with "illegally obtained or retained 
software"— as more exact (if also more wordy) than "pirated software". One's reasons for 
choosing one wording of a clause over another can depend on the most pedestrian 
considerations— and may not be obvious from the mere preference. 

^° Email (Gotbertem) Febmary 17, 2004. Gotbertem wrote me about these troubles only a 
few months after they had been resolved (November 17, 1997). His description is woith quoting 
(GotberternVSteering Commitbee\MIKENOV): "The technical confusion— someone else 
graciously let me use their listserv. As E-mail addresses change— your identity changes (a 
Humean problem:-)) and you get denied access to a list. As my E-mail address changes, I too get 
denied access. Since I am the guy enpowered to change E-mail addresses on the list and my 
identity has changed, I need to E-mail the system managens at the Urdvensity of Tennessee to 
change things." 

^ ^ Febmary 10, 1997 (Principle 1, Comment 3). 

'^ It did pass. As a result. Version 3 read: 'In particular, software engineers shall: . . .2.08. 
Donate professional skills to good causes v\ten opportunities arise and contribute to public 
education with respect to the discipline." Why did they not divide this into two provisions (rather 
than paste them together with that "and")? 

' ^ Jewett, v\to had become editor of SIGCAS the year before, taught conpjter science at 
California State University-Long Beach (including a course called "Conpjter, Ethics, and 
Society"). Hs specialty was databases and web design devdopment He nonetheless considered 
himself to be an engineer (with a "small e")— based in part on an engineering degree collected in 
the course of an eclectic education: "I have a bachelor^ s degree from the University of Illinois in 
music education (1965). I have a master's degree in electrical and conpjter engineering from 
UC- Santa Barbara (1980) and a master's in systems management (USC, 1987). And I have PhD. 
work (but no degree) in "Conpjters, Organizations, Policy and Society" [an interdisciplinary 
program at the UC-Irvine] in the late 1980s." His first computer job was in 1971— with punched- 
p^:er-t^:e storage and program debugging in octal machine language— in his fourth year in the 
United States Air Force. (He enlisted in the Air Force after a draft notice ended a two-year career 
in education, as director of band and orchestra in a public school in Rockford, Illinois.) For a 
time, he served as a software acceptance-test leader and technical-manual writer. Later, he 
developed and advocated user requirements for advanced communication systems. At retirement 
from the Air Force (1987), he was program manager for development and acquisition of one 
segment of a major satellite system Interview of Jewett, October 31, 2003. 

' * Editors seem to be more conservative about grammar in general— and split infinitives in 
particular— than most people. Jewett and I seem to have cast the only two no votes on question 
2. 

'^ Gotberbam\Version2-2a-2.1\Taskforcevoteson2.1 changes\votetom 
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^^ Following these comments is an unexplained email address for "Pete Coad" (probably 
pasted in by accident). 

" AlsoinGotted)am\Veision2-2a-2.1\Taskforcevoteson2.1 change^voteed 

' ^ Gotiie±am\Veision 2-2a-2. l\Task force votes on 2. 1 changes\voteben (direct); August 8, 
1997 (KankD, using listserv, also in GottedemWension 2-2a-2.1\Task force votes on 2.1 
changes\votemaric); GottedemWension 2-2a-2.1\Task force votes on 2.1 change^voteflug 
(direct); GottedemWension 2-2a-2.1\Task force votes on 2.1 change^voteman (direct); and 
August 8, 1997 (Prinzivalli, using listserv). 

'^ AlsoinGotted)am\Veision2-2a-2.1\Taskforcevoteson2.1 changes\votdunc. 

^° Two responses seem not to have survived: Ilene Bumstein's and John Weckert's. We 
know they must have existed because Gotterbam cited them when he reported the final vote on 
September 17, 1997 (GotterbamWersion 2-2a-2.1\Task force votes on 2.1 changes\SRl). 
Bumstein may have used her ballot to correct her name. From here on she is "Ilene", not "C.S." 

^' There may be another factor contributing to both my dissatisfaction with the (minor) 
changes in the code and my sense of having passed it on to others. I was quite sick from 
February through May. 

^^ October 10, 1997. This email (again) promised to send a disc containing the electronic 
version of his email files. Mechler also remaited that he had seen "your comments [presumably, 
rriy ballot] and wondered v\^ your name isn't on the document?" If I had not noticed the 
omission eariier, I now must have. I believe it was about this time that I asted Gotterbam v\^ he 
had omitted niy name (and Weil' s) . He responded that he had thought we wanted to be invisible, 
that we had never said we wanted to be listed, and that the message that went with Version 2.1 
said we would be listed only if we said we wanted to be. But, if we now wanted to be listed, he 
would be happy to list us as soon as possible, that is, in (v\tot became) Version 4. There is no 
p^:er record of this exchange. My memory is that it occurred during a phone conversation 
Gotterbam has the same memory but (wisely) wonders "if we are right". Gotterbam Ch^D8cmt 
(Septen±er28, 2004). 

^^ GotterbamWersion 2-2a-2.1\Task force votes on 2.1 changes\SRl. This is not the 
original email but Rogerson's response (August 18, 1997) containing the original with his 
answers inserted. 

^ * This is especially plausible for Barber v\to had resigned from SEEPP October 21, 1996, 
without doing any work on the code itself. GottedemVSteering Committee\Barber. See also 
Interview of Barber, November 14, 2002. 

^^ For Version 2.1, Gottedam had used the opposite ^Dproach, letting people tate their 
name off by express request (April 24, 1997). Versions 3's list is missing one name present on 
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Version 2.rs, Mary Prior's. She specifically asked to have her name removed because she did 
not think she did enough to deserve listing. (Gotterbam, having the work of others listed to 
compare with hers, is adamant that she did deserve listing.) Gotterbam\People\Primary People. 

^^ To the procedural aspects of process noted here, Gotbeatam would add something about 
the executive commitiee's sprit: "Tliis level of commitiiient of the executive commitiee was 
typcal— went to unreasonable efforts to respond and teep the process going— this level of effort; 
was common and was a major contribution to finishing the project" Gotbeibam Ch^DScmt 
(September 28, 2004). 

^^ GotberiDam's listing of respondents' comments under 18 includes one (KankD's) vMch 
mates an inpjrtant general point about the stmctuie of the code (one the pecemeal process of 
amendment threatened to ovaiook) : 

Note that the proposed change [in 8.08] doesn't fit in grammatically with the last phrase 
of Principle 8: namely, ". . .software engineers shall continually endeavor to:". That is to 
say, the last phrase in the body of any of the principles is really the beginning of the 
sentence that is conqieted by each of the numbered items after the body of the principle. 
So read the last line in the body of any of the principles and follow that with any of the 
numbered (e.g. 8.08) items. The result should be a conplete, grammatically-conect 
sentence. Something to check in the other principles? 

KankD' s point is easier to see if we actually write out the sentence as he instmcts: "In particular, 
software engineers shall continually endeavor to:... 8.08 Consider violations of this code 
inconsistent with being a professional software engineer and encourage colleagues to adhere to 
this code." "Considei:^' is just too weak to follow the already weak "endeavor". Clause 8.08 
seems to be the only exanqie in this version of the problem KankD identified 

^ ^ Version 2. 1 had: "Keep as confidential inforaiation gained in their professional work that 
is not in the public domain (aid not inconsistent), wtere such confidentiality is consistent with 
matters of puliic concern." (The parenthesized "and not inconsistent" looks lite it was pasted in 
ty mistate.) Conq^are with Version 1: "4.05. Keep as confidential information gained in their 
professional work that is not properiy in the public domain" 

^^ Communications of the ACM 40 (November 1997): 110-118. Computer 30 (October 
1997): 88-92 also published the code and ballot but omitted them from the table of contents. 
They were republished in Computer 30 (November 1997): 88-92, this issue including them in the 
table of content. 

^° GotieriDam's Septen±ier 5 email to Frailey seems to have been a response to a request 
from Felipe Cabrera (tte Steering Committee' s chair) for a "status report". Whether this email is 
the stahjs report itself, Gotterbam's attend to get the "lay of the land" before submitting the 
official report, or just another attend to get money for a face-to-face meeting of the executive 
committee, is unclear. The Sutgect of the email ("Meeting of Executive Committee") suggests 
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the third. There are in addition at least three reasons to think it is not the official report. First it is 
addressed to Frailey, not Cabrera; second, it seems too informal; and third, Gotterbam's next 
email to Frailey (Dennis2) says that the "status report [indicated that] we are polling the 
membership of the lEEE-CS and ACM about the Code and will have the results in mid- 
November" but the September 5 email says nothing about polling. While Gotterbam has no 
memory to answer these questions, he has a suggestion: "you must keep in mind that sometimes 
people press the reply button to a message that may be about X (status report) and the body of 
the message may be about something else. The convenience of pressing reply sometimes 
misleads one about the message content." Gotterbam ChapScmt (September 28, 2004). 
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GotbederriySteering Coinmitljee\Dennisl 1 . 



^^ Gotlie±)am\Hisbory of SE Code\Hisboiy Expanded Gotbeatem does not think receiving 
the news from Erailey was unusual. His communication with the Steering Commitbee was 
generally through Frailey. Indeed, he can recall only one email from Cabrem during Cabrem's 
tenure as chair. Gotbeatam Ch^D8cmt (September 28, 2004). 
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Gotberi3am\Steering Commitbee\Dennisl 1 . 



^* Gotberi3am\Steering Commitbee\Dennis2. Though the salutation is 'Dennis", the email's 
only (electronic) version is an email sent to Gotbertem. One reason to believe that the email was 
sent to Frailey at about this time is that subsequent events seem to presuppose some such 
communication as this— and there is no evidence of any other. 

^^ After Gotteibam's signature is the announcement of 'TSTew Email and Phone Number^'. 
The new ETSU email may have added to his difficulties with the listserv. 

^^ Gotberi3am\Vei:sion4\AABIL. This is probably the text of v\tot became an email. 
GotberiDam explicitly says in the second paragi^±i that "Each person is sending in a proper 
expense accounting, but I thought it would be helpful to let you see the total pcture so you could 
clear ariy difficulty Miller might get into from the accountants [because he wants some money 
from each society]." The receipts would have had to acconqsny a letter sent by "classic mail"; 
there was then no way to serd receipts by email. Gotteibam must therefore have written the 
letter (and posted it) and then pasted it into an email (as a "heads up") 

" Notkia v\to was a member of the Department of Conpjber Science and Engineering, 
University of Washington, holds a BS from Brown University (1977) and a PhD. from 
Camegie-Mdlon (1984), both in Conpjter Science. He had just become SIGSOFT chair. 
http://www.es. wasMngtonedu/homes/notkirL 

^^ Gene Hoffnagle, v\to held a BS in Mathematics from Case Institute of Technology 
(1967) and an MS in Corrpiter Science from Johns Hopkins University (1976), worted as a 
researcher at IBM's Centers for Advanced Studies (Yorktown, New York), (www.conpjter. 
org/csinfo/BIOS/gene.htm). (He declined to be interviewed) Apparently, Hoffnagle was coped 
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because he was then chair of lEEE-CS's Technical Council on Software Engineering (TCSE), 
succeeding Elliot Chikofsky. 

^° We seem not to have this email. I am lemnstmcting it from an email that GottedBm sent 
himself on October 14, 1997 (GottedamWension 3\Survey Comments\TCSE-l-5). That email 
consists in large part of an email Laurie Werth sent him on October 10, a pasting together of 
parts of at least two other emails: a note to "Gene and Leonard" from "Cari" (to be described 
below) and the note from Leonard (Tripp) to Gene and TSCE (already quoted). Tripp will 
become increasingly central to our story from now on 

*' Gotterbam's response to Tripp's instmctions may be the first hint that he is thinking of 
re-titling the code: 'This [Tripp's second instmction] is contrary to the committee interest in 
professional practices. Should we read the Code of Ethics to include the word 'Conducf or 
'Practice', e.g., 'Software Engineering Code of Ethics and Professional Practice'??" Rather than 
attenpt to distinguish ethical issues from technical issues, Gotteibam is suggesting using the titie 
of the code to mate the distinction urdnportanL That is exactiy v\tot the ACM had done in 
labeling its 1990 code: "Code of Ethics and Professional Conduct". 

^^ For more on this way of defining "ethics" (and for a corresponding universal definition of 
"morality"), see my: Ethics and the University (Routledge: London, 1999), Chapter 1; or Ethics, 
Code, and Profession (Ashgate: Aldershot, England, 2002). For more on what I mean by 
"rational best", see my "Brandt on Autonomy", in Rationality and Rule-Utilitarianism, ed. Brad 
Hooker (Westview Press: Boulder, CO, 1993), pp. 51-65. 

" Dissatisfaction with the speed of the process seems to come primarily, if not entirely, 
from the ACM-^Dpointed men±)ers of the Steering Committee (Fddmai, Frailey, Boehm, Shaw, 
Zweben). I therefore wonder v\teher the ACM men±)ers may bring a different sense of time to 
the process than the lEEE-CS members. The ACM produced its code in about eighteen months. 
By that yardstick, the Joint Steering Committee's worlc was way behind schedule (thirty four 
months and counting). For the lEEE-CS members, on the other hand, the IEEE Standards- writing 
would be the yard stick. By that standard (average time for writing a standard seven years), 
SEEPP was well ahead of schedule. That Cabrera seems a much less active chair than Barbacd, 
leaving much of the day-to-day worlc to Frailey, may have made Frailey (in effect) the chair, 
adding to ACM' s weigli in deliberations during 1997. 
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Gotterbam\SEEP 1996-97\NOTOBJ. 



* ^ Gotierbam\SEEP 1996-97\NOTSI (tiiat September 26 email is at tiie end of tiis October 
28 email). 

" For one such criticism, the problem seems deeper. As Gotterbam puts it, "How do we 
handle this? He knows he should not read the single bullet and that it is handled in [other] 
sections of 3, but then insists on reading 3.07 as a stand alone item" 
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^^ Michael Davis, Thinking Like an Engineer (Oxford University Press: New York, 1998). 
Here we see one disadvantage of having an executive board without a single member trained as 
an engineer. The sense of "technician" intended is, of course, that appropriate for categorizing a 
mechanic, lab technician, or the like (rather than in the sense in which anyone working in 
technology is a "technician"). 

*^ Febmary 10, 1997: "5. replace 'salai/ with 'remuneration' ." 

" See, for exanple, ABET Guidelines 5.f: "Engineers shall not falsify nor permit 
misrepresentation of their, or their associates', academic or professional qualifications. They 
shall not misrepresent nor exaggerate their degree of responsihality in or for the sutgect matter of 
prior assignmmts. Brochures or other presentations incident to the solicitation of enqioyment 
shall not misrepresent pertinent facts concerning enployers, enployees, associates, joint 
ventures, or thdr past acconqiishments with the intent and purpose of enhancing their 
qualifications and work" 

^° There seems to be a similar dynamic for other provisions Notidn criticized Version V s 
equivalent of 1.06 ("Ensure good management for ariy project on v\Mch they work, including 
effective procedures for promotion of quality and reduction of risk") was: "Assure proper 
management on ariy project on v\Mch ttey work, including proper procedures for control of 
quality and risk." The terai "proper^' left more room for interpretation, perh^:s avoiding Notidn' s 
concerns with niches. Version 1' s equivalent of 1.14 ("Promote maximum quality and minimum 
cost to the enployer, the client, the user, and the public. Mate ariy tradeoffs clear to all parties 
concerned") had been 1.13: "Promote maximum productivity and minimum cost to enployer, 
customer, user, and public." There is no mention of making tradeoffs clear to ariyone. None of 
these provision would survive into Version 4 (or, at least, survive in anything lite their original 
form). 

^^ GotierbamWersion 3\Survey Comments\replytonotk. The file date is 12/3/1997. The 
letter itself is not dated and gives no indication of having been sent as an email (except for the 
heading "Sutgect: SE Code comments". Gotterbam's archives contain several drafts from the 
middle of Noven±)er— with requests for comment from 'Team": 1) Gotterbam\SEEP 1996- 
97\TONOTRPL, identical to tiiat in anotiier file witii tiie sane date (Gotterbam\SEEP 1996-96\ 
NOTRPLDN); and 2) Gotterbam\SEEP 1996-97\NOTRPL, from tiie day before. 

^ ^ For details concerning these responses, see next ch^Dter. 

^^ See, for exanqie, D. Price, "PentiumFDIV flaw-lessons learned". IEEE Micro 15 (April 
1995): 86-88. 

^* The letter actually (twice) refers to this clause as "6.15", but the language makes it clear 
that 6.13 is what is meant (and there is no 6.15). Notkin's original has the clause number right. 
Odd slip in an otherwise carefully prepared document. 
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^^ We are now a long way from Vension 1' s sinple idea: "1 . 14. Avoid fads, departing from 
standard practices only v\ten justified" 

^^ In fact, 3.07 survived all the way through the final Version 5.2— in a somev\tot revised 
form (as 4.06) : "Refuse to participate, as members or advisors, in a governmental or professional 
body concerned with softw^ related issues, in v\Mch they, their enployers, or their clients have 
undisclosed potential conflicts of interest." 

^ ' That is, on Version 3. Notkin made one unofficial comment a year later on Version 5.2. 
GotteriDam recalls: 'In October 98 I gave a presentation on the Code at the SIGSOFT annual 
conference. . .v\tere I met NotkirL At that point his only question was v\^ we con±aned into one 
document a code of practice and a code of conduct" Gottertam email (February 22, 2004) . 

^^ GotterbamWersion 3\Survey Comment^TCSEl-5. This is the October 14, 1997 email by 
v\Mch Gotterbam forwarded Werth's October 10 email to Miller and Rogenson I am ignoring 
the comments contained in the Corfu meeting of the IFIP SIG9.2.2 (May 7, 1997) because, 
though they arrived about this time (October 7), they concerned Vension 2, not Vension 3, and 
have already been discussed in the preceding ch^Dter. While they probably went into the mix of 
comments in Gotterbam' s head, th^ did not go into the summary of comments Gotterbam drew 
up in December in preparation for revising Version 3; there is no evidence that Gotieibam even 
passed them on to his executive committee. They were by now obsolete (as well as much more 
negative than he had supposed v\ten he first reported to SEEPP v\tot he had heard about them 
from the meeting' s chair) . (8.7) 
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Chapter 10: Slogging Toward 'Version 4.DONE 
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"Build a system that even a fool can use and only a fool will want to use it." 
— Murphy's Technology Law #49 

10.1 Another worrying silence 

About the time Version 3.0 (9. Appendix) appeared in the October 1997 issue of 
Computer, Gotterbam began to receive comments from (more or less) ordinary members 
of the lEEE-CS and ACM. The first arrived on October 11.^ It was from Stephen Unger. 
Then chair of Columtaa's Department of Conpjter Engineering, Unger had long been 
prominent in engineering ethics.^ In part, his prominence was scholariy. He was the 
author of ControHing Technology: Ethics and the Responsible Engineer (1994) as well as 
of several much- discussed articles.^ In part;, though, his prominence was practical. Long 
active in IEEE, Unger had an inpjrtant part; in drafting three codes of ettdcs. The first, 
the IEEE code of 1979, had been replaced (in 1987) by the second he wori^d on That 
one survived only three years, its short; life a record in the history of codes.* What 
replaced it was the much shorter (ten-commandment-slyle) code still in force in 1997 
(fflid today). Unger had no part in writing that one. Between these codes, he had helped to 
write one more, the innovative but soon-forgotten 1984 code of the American 
Association of Engineering Societies ( AAES) . Unger had bad luck with codes. 

Unger found Version 3 "an inp^ssive document, full of interesting, inpjrtant 
points, covering a wide range of topes in considerable detail." Having noted that 
GotberiDam's committee had "cleariy decided to go for conpleteness as opposed to 
brevity, the opposite of the choice made by the IEEE, he expressed some satisfaction (in 
parentheses) that "the IEEE Ethics Committee plans to atterrq* to get the best of both 
^Dproaches, by devdopng, over a period of time, an extended set of guidelines for the 
[1990] IEEE code."^ Then, after ^x)logizing for not giving the Code the "careful study 
that it deserves", he made ten specific suggestions that together give the irrpession that 
he must have read the code carefully. (He also refened Gottertem to the 1991 Swedish 
Ethical Rules for Con^Duter Professionals that he had ^Dpended) Unger' s first suggestion 
gives a good indication of the rest: "Although your item 1.07 ['Ensure realistic estimates 
of cost, scheduling, personnel, and outcome on ariy project on v\Mch they work or 
propose to work and provide a risk assessment of these estimates' ] is similar, the wording 
of item 3 of the Swedish code is very nice and peih^:s might suggest some adjustment in 
your statement..: 'only tate part in projects with liie time and resources to do a good 
job.'" (Unger' s codes tended to sound as if Hemmingway, rather than a corporate 
attorney, had done the writing— they were always easy to read) Though Version 4 did 
not incorporate this suggestion, it did incorporate several others, including Unger^s 
second: 2.06 ("Be fair and truthful. . .) should instead be "Be fair and avoid deception" 
because, as it stands, it seems only to proMtat falsehood The revision would nnte it 
clear (as, ^parenfly, "fair^' does not) that a software engineer should also avoid 
deception by "not disclosing information, in other words, deception by omissiorL"^ 

The next set of comments arrived one day later, October 12. It was the first to 
mention Computer as the source of the code. The respondent, a member of both the ACM 
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and the lEEE-CS, wrote from Cedar Rapids, Iowa, that he "generally" favored Version 
37 But he did have "some trouble with the wording of 3.07 ["Refuse to participate in ariy 
decision of a governmental or professional body. . . ]"— enough trouble to vote "uncertain" 
on that provision (and only on that one) . He then filled the rest of the one-page email with 
an explanation of v\tot troubled him It was v\tot had troubled Notkin about the same 
provision— except that the respondent in Cedar R^ds thought the provision too narrow 
as well as too broad Limiting 3.07 to "governmental and professional" bodies would 
leave "a loophole for conpary based activities." He therefore recommended shortening 
3.07 to something lite "Avoid conflicting financial interests." He then gave an exanqie 
of the situations that he meant this revision of 3.07 to coven 

While I was contracting to a corrpjter manufacturer, that manufacturer was asked 
to co-develop a product for a tealth care provider. Our allegiance fell among 
several enployens, customers, and users. However, it was possible to render 
opinions on equipment and standards to each conpary involved without feeling 
taas for the con^Bnies v\to were not inpjrtant at the time. Our group was placed 
into a tmsted position and all participants knew the relationship. This sort of 
conflict may easily result v\ten a single enployer and product relationship is not 
established This is often the norm these days. 

The respondent from Cedar R^ids did not explain v\tot troubled him about 3.07 or v\^ 
it was not resolved ty 3.06 ('T)isclose to all concerned parties those conflicts of interest 
that cannot be reasonably avoided or esc^:ed and aspre to resolve them"). Perhaps he 
did not think there was any reason to "aspre to resolve" them in the exanple he 
described Why then did he want to broaden 3.07 (since broadening it as he proposed 
would make 3.06 pointless and rule out the very arrangements he described so 
approvingly)? Clearly, there was something wrong with 3.06 and 3.07, either individually 
or in the way they interacted, but v\tot was not clear was v\tot was wrong— and how to 
fix it The problem was not logical, but something in the way (some) users would read the 
clauses. 

Then, for almost two weeks, there was a disturtang silence— not only no 
comments but also no ballots. The instmctions in Computer had been clear. All ballots 
and comments were to go to Gotterbam. What explained the silence? One possibility, not 
a very likely one, was that no one else had noticed the code because all reference to the 
code, ballot, and accompanying explanation had, unaccountably, been omitted from the 
table of contents. Computer had already undertaken to correct the omission by printing 
everything again in the November issue— this time being sure there was a reference in the 
table of contents. And, of course, the Communications of the ACM would also be 
publishing the code, ballot, and explanation in November. SEEPP was now definitely a 
month behind schedule and, without a reasonable number of ballots, definitely in trouble. 
The Steering Committee would have little interest in continuing with the code without a 
strong vote from the membership. Three years of work would be lost. Y et, there was little 
Gotterbam could do now but push on, hoping that the comments would soon pour in. 



272 



10.2 From silence to SEERI 

On October 23, the first ballot showed up in a three-page email from Omaha, 
Nebraska (with contact information at a corporate address). A page and a half of the 
email consisted of a long double column: on one side, the clause numbers (without the 
principles); and on the other, SF, F, or one of the other answers the survey had allowed. 
Most of the clauses had an F after it (Favorable). Almost two dozen had SF (Strongly 
Favorable). There were six U's (Uncertain).^ There were, however, two O's (Opposed) 
and even one SO (Strongly Opposed): 1.12.^ Following the ballot were comments 
explaining one U (2.01) aril all the negative votes (except for "8.08 Consider code 
violations inconsistent . ."). Some explanations raised inpjitant points. For exanqie, our 
Omaha respondent offered three reasons for voting against 1.12 ("Delete outdated and 
flawed data. . . ")— the one Strongly Opposed: 

First, with respect to the data, flawed or outdated data can still be meaningful in 
other contexts. Second, although it is tendered with the "v\tere appropriate" 
clause, the action of the statement has a direct inpact on the data and places the 
Software Engineer in a precarious position. Data are the persistent artifacts of 
^plication. Generally, tte user of the software or other individual should be the 
steward of data contert, not the Software Engineer. Finally, if a statement 
regarding data quality is to appear in the Code of Ethics, it should place the 
Software Engineer in an advisory role to the steward of the data, not in a role to 
act upon the data. A more acceptable statement would be something lite: 
"Promote understanding and awareness of the data quality and data management 
issues that surround the data that affect the product" 

Clause 1.12 began with Version 2. The corresponding provision in Version 1 ("Assure 
that raw information used in software is accurate, derives from a legitimate source, and is 
used only in ways property authorized") was not sutgect to any of these three criticisms. 
Our Oniaha respjndait (without knowing it) also otgected to other ways in v\Mch 
Version 3 differed from Version 1 (without knowing ariyfhing about Version 1). For 
exanple: He proposed removing from 2.01 ("Disclose to ^Dpropriate persons or 
authorities ariy actual or potential dangers to the user, a third party, or the 
environment . . ") exactiy v\tot SEEPF s executive committee had added: 

Maybe it is just the phrasing of the statement but I would strife the final phrase 
("or merely know ctout") from this statement I also would strife 'acliual or 
potential' . With these corrections, I would have respjnded 'Tavoi" to this item on 
the survey.'" 

The Omaha resp)ndent seemed to have no otgection to the substance of the provision, 
merely to its tone or perii^:s just to its legalistic precision. 

Not all of his comments were reserved for ways in v\Mch Version 3 differed from 
Version 1. Three of his comments concern ways in which Version 3 resembled (or was 
identical to) Version 1. The most interesting, perii^:s, concerned 2.07 ('TSbt put self- 
interest the interest of an enployer, the interest of a client or the interest of the user 
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ahead of the public's interest")/^ TMs is (along with Principle 2) the Software 
Engineering Code's (somewhat weatened) version of v\tot engineers call "the 
paramountcy clause" ("Hold paramount the public health, safely, and welfare"). In some 
form or otter, it has tecome a standard feature of engineering codes both in tte United 
States and elsev\tere. Tte Omaha respondent nonetheless otgected: 

I think this statement is problematic. I think that it is inp^rtant that self-interest 
not subvert tte interests of tte enployer, client or public; tewever, the statement 
is too an±atious v\ten it promotes the public interest ahead of that of the 
enqioyer. If the Software Erigineer has adequately "prequalified" the enployer or 
client and determined that the enployer or client is not actively working against 
the public interest, then I suggest that it is the responsiMity of the Software 
Engineer to advise the errqioyer or client regarding ariy concerns relative to tte 
interest of the public at large. In this manner, the SoAm^ Engineer can play the 
role of educating those with tte alility to affect tte public interest 

Since our Omaha respondent thinks of software engineers as mere advisors, it is hard to 
see v\^ te opposed 2.07. 1 do not think te is suggesting that it is enough for a software 
engineer to point out tte public interest to a client or enployer vMle recommending a 
course of action contrary to that interest' ^ 

While most of tte suggestions of our respondent from Omaha seem intended to 
weaten or at least soften tte tone of Version 3, one does not' ^ His otgection to 4.07 
('Inform v\ten tte project becomes problematic. . .") is that it is "too weak". He ttought 
that "[in] addition to informing, tte Software Engineer should provide additional 
substantiation for his or her opiniorL" It is inpjrtant that tte software engineer "maintain 
a documentation regarding tte informing of the client or enployer''. 

That was tte last comment for a week Then, on Novemter 2, there was a brief 
email from someone concerned with "assistive technologies". After saying that "[this] 
looks lite a great effort and I wish you well", te quickly got down to business. He 
wanted to amend 2.05 ("Endeavor to produce soAm^ that respects diversity...") to 
include "sensory access" or "sensory atalities" (among tte issues specifically mentioned 
"language, different alilities, physical access, ..."). As 2.05 stood, te reported, te had "to 
read very broadly to understand that 2.05 includes tte needs of tte visually inpaired and 
tte hearing inpaired" He concluded with thanks and tte tepe that "v\ten I review this 
more in detail, perhaps I' 11 send you more comments.' * 

Almost another week passed before tte next comment arrived, this one a page 
long from a young faculty men±)er in Conpjter Science at tte University of North 
Carolina He was careful to say that tte comments were on Version 3.0 "as pjblished in 
tte Novemter 1997 issue of Computer". He then made ten comments, each signaled by 
the reference number in the code. Two were simply suggestions for amendment (witii 
specific wording but no explanation): for both 1.05 ("ensure appropriate methodology") 
and 4.02 ("Ensure... document., approved for use"), "add: except with the knowledge 
and consent of all parties." Some suggestions indicate a problem as well as offering an 
amendment for example "1.07: Again [as in 1.06], this is management's job. If the word 
"Ensure" were changed to "Provide", then I'm happy. Otherwise, I strongly disagree." '^ 
Some comments express doubts of one sort or another. For exanple, te said of 5.03 



274 



("Assign work only after taking into account appropriate contributions...")/ "I don't 
understand what this means." In only one place did he seem to misread the code. Of 5.07 
{"Offer only fair and just remuneration"), he wondered, "Why would I not accept 
whatever the hiring company wants to pay me, so long as the payment is not illegal and 
does not require me to do something unethical. What would be unfair renumeration 
[sic]?" Because he misread 5.07 (supposing it to apply to acceptance of remuneration 
rather than to offers), he said of the always troublesome 6:07 "Redundant with 5.07, and 
confusing for the same reason." He then took much of the sting out of these comments by 
ending his message: 

Good work putting this all together! This is a tremendous task, especially 
with all the opinions there will be from various people and groups. This has the 
potential to really state a direction and push SEs into more right-thinking action; 
perhaps even to modify behavior within software design houses to the benefit of 
us all. Thank you for putting in the hard work to help bring this about.^^ 

Then almost another week passed without a comment on the Code. Gotbeatam 
had less time to wony about the silence than we might at first suppose. He was, of 
course, again teaching full time, but he was also setting up the "Software Engineering 
Ethics and Research Institute" (SEERI). SEERI was in part a way to promote the Code 
once it was adopted Its website would cany the Code v\teher ACM' s website or lEEE- 
CS's did or did not He had already seen the advantage this would have. Most people 
seemed to have found Version 3 easier to access through Rogerson' s (small) website at 
DeMontfort than through the much larger (and, therefore, harder to use) ACM or lEEE- 
CS sites. Gotterbam also planned to use the SEERI website to list conpardes that had 
adopted the code (and thereby encourage othej:s to do the same). Tie site vvould be a vvay 
to mate available research on software engineering ethics— and on related topes such as 
licensing, course materials for teaching software engineering ethics, and ethics 
conferences. The website might even provide a place for ethics-related humor (such as 
Sam Redwine' s quip, "Software and cathedrals are much the same. First we build them, 
then we pray ! ") . SEERI could offer seminars on software ethics, consult with individuals, 
organizations, and government, and even undertate m^or research on software 
engineering ethics.' ' East Tennessee State was so pleased with SEERI that it had freed 
Gottertem from the usual administrative duties of faculty and provided a graduate 
student to maintain the website and otherwise help with SEERI' s day-to-day operation 

10.3 A positive response 

While waiting for the flood of ballots to begin, Gotteibam also wrote his task 
force (using the listserv) to announce that "worlc on the code must start again". This 
November 1 1 email reported the publication of Version 3. 1 (and v\tot had gone wrong in 
October), noted that tte "articles" in both Computer and CACM contained "a survey for 
each item in the code" and that "responses are already coming in", and observed that "we 
should feel good about our product." But, he continued, the comments also "indicate that 
we are not done yet". There are "helpful comments" ranging from "things which are easy 
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to adjust to those which are not easy". Gotterbam promised to organize the comments 
and "send them to you in a few weeks for your input." 

Mechler responded (through the listserv) two days later (November 13, 1997). He 
had bad news: "In Computer Nov there isn't any reference in the Index. There is a Call 
for Participation on page 57." Even worse, "[the] web addresses on page 90 (survey) are 
not correct (same as on 57)." When he went to "What's New on ACM[J Third one 
[presumably, Version 3] will not come up." Mechler ended by asking whether the survey 
is on a web page. Less than two hours later, Mechler answered his own question: "The 
third one is [at] the Centre for Computing and Social Responsibility [Rogerson's 
organization] and their correct site is http://www.ccsr.cms.dmu.ac.uk/[.] The article had it 
mistakenly as ccsr.cAs..." (The capital A indicates the error: it should be a small M.) 
Mechler concluded by reporting that the ballot "is not on any web page". Only the code 
is. 

Gotterbam immediately forwarded this bad news to the Task Force, preceding it 
with an unrelated request for help.^^ The Steering Commitbee had asted him for some 
responses from "corporate players, in addition to the individual responses." He was 
thaefore asking ariy member of the task force v\to knew someone v\to could "speak for 
aconpariy oram^orareaof thecon^Miy such as systems development" to get the code 
and ballot to the ^Dpropriate person Why the Steering Committee should have asked 
Gotterbam to recnrit corporate responses is not clear. The Steering Committee had 
several members v\to would at least seem to have had much better corporate contacts 
than SEEPFs executive committee (Cabrera, at Microsoft; Frailey, at Texas Instmments; 
Tripp, at Boeing; and so on). The same Steering Committee that only a few weeks before 
had sought comment directly from the TCSE and SIGSOFT now wanted Gottertem, at 
East Tennessee State, Miller, at University of Illinois- Springfield, and Rogerson, at 
DeMontfort University, to seek comment from corporate America Was the Steering 
Committee also seeking such comments? Had they tried during the intervening month to 
get such comments and failed? Or were they just raising one more hurdle over v\Mch 
SEEPP would have to junp to bring work on the code to conpletion? Gottertem could 
only wonder and try to do v\tot was asted 

Gotteatam received the Steering Committee's request several days before he 
passed it on to the task force on November 13.' ^ On November 18, Mechler emailed the 
^Dpropriate person in his conq^ary, asking him both to respond as GotteriDam requested 
fflxi to pass on Gottertem's request to other chief information officers (CIOs) he knew. 
On November 20, Mechler^ s CIO wrote back with one name (and an email address).^" 
Mechler then wrote (using the listserv): "One on the way CIO of Equitatie Resources, 
Inc. Talking to another two." That was the last help Gotteibam got from the task force in 
recruiting corporate response. By the end of December, GotteriDam had several other 
corporate responses; some recnrited from the contacts he was devdopang for SEERI, 
otters just anived unsolicited 

While GotteriDam was making up his mind v\tot to do with tte Steering 
Committee request, te received a second ballot, this one with a Texas Instruments (Tl) 
address (November 11).^' Tte ballot had only four U's (and no O's or SO's): 1.12, 2.02, 
2.05, and 3.08. There were only three brief comments. Ttough favoring 1.09 ("Ensure 
adequate testing, debugging, and review of software and related documents on v\Mch 
they work), our respondent at Tl ttought that "[ensuring] adequate testing and debugging 
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is partly the responsibility of the product provider but more so, the responsibility of those 
purchasing the product.' There is no ejqianation for the U vote on 1.12 or 2.02,^^ but 
concerning 2.05 ("Endeavor to produce software that respects diversity..."), our 
respondent at Tlotgected, 'Targeting the audience of software users should be more of a 
concern/goal than trying to attack world-hunger with each software produced. . .if s a hat 
to[o] forward looking." What had brought on that reference to "world-hunger"? Was it 
the Code' s explanatory sentence following the clause itself ('Issues of language, different 
alilities, physical access, mental access, economic advantage, sindaUocation of resources 
should all be considered")? Clause 2.05 was, Gotterbam thought one of the ways 
Version 3 had improved on Version 1. Another improvement was 3.08 ("Temper all 
technical judgment by the need to support and maintain human values"). That clause, the 
only other about which the respondent at TI had anything to say, elicited his most 
negative comment: 'This principle seems too ambiguous. I cannot envision restricting 
technological judgment on the basis of any ethical situation." 

The next set of comments to arrive was the first to mention the November issue of 
CACM as the source of the code. Its author, a principal in his own consulting service in 
San Antonio, began by "applaud[ing] the inclusion of language that stresses the 
importance of properly testing software systems prior to release." Indeed, he generally 
liked the code. But there was one provision he did not like, one of the innovations of 
Version 2 that had already come in for considerable criticism, clause 2.05 ("Produce 
software that respects diversity... "). The respondent from San Antonio devoted a page 
and a half to his five reasons for deleting the clause: "1. It's vague.... 2. It's 
contradictory... . 3. It's pointless... . 4. It's dangerous... . 5. It's unnecessary... ." He then 
concluded with a paragraph that epitomized the whole: 

In Stalinist Russia, few examples so capture the fallacy and stupidity of socialism 
as "Socialist Science". Scientists bent their knees to the Communist Party and its 
tyrants, pursuing all sorts of ridiculous theories because they met with the 
approval of the Soviet hierarchy, turning their backs on the truth. I dont want to 
suggest that this subsection is on the scale of that grotesquery, but I do want to 
point out a parallel: All science must be ethically and morally informed, but it 
must not take sides in political matters. Of course, I grant anyone the right to view 
respecting diversity, however one defines it, as a pillar of one's personal ethics; 
however, I ask that this code not make it a mandatory part of the ethical values of 
every software engineer. 

Clearly, clause 2.05 was in trouble. 

The next day two more ballots arrived with comments, as well as some without; 
the day after that, a very long response, as well as some ballots without comments; the 
day after that, two more ballots with comments, as well as some without; and, before 
long, the tickle of response had become a small stream (about 40 ballots in all).^* By this 
time (November 18), Gotterbam (with the help of an honors student his department had 
assigned him for the purpose) had organized tte comments into a single dociiment, thirty- 
one pages single-spaced^ ^ Gotterbam sent it to the task force (in two parts) on November 
20 (using the listserv), with a cover memo explaining v\tot to do with it After the 
salutation ("H Team"), the memo acknov\dedged "Ed's email about Industry irpjt' and 
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reported that Gotterbam had "contacted some multi-nationals, Lockheed Martin, TRW 
etc and we are getting statements from them." Gotterbam again asked the task force to 
find corporate leaders (a "CEO") to respond, stressing that any such leader should 
"indicate that they are a CEO". He stressed this, he wrote, because "[he thinks] the 
steering committee's intent is to specifically identify the industry view." If the CEOs do 
not identify themselves as CEOs, how is the Steering Committee to know it got the 
industry view? He then turned to the comments (with the introduction, "Time to get back 
to work:-)" in capitals). 

Gotterbam had for some time been getting "responses from materials in the two 
magazines and on the web". Some are "useful and others are not so useful". He had 
included everything. The presence of a comment in the document "attached" (meaning, in 
those last days before attachments, below) did not "indicate support of the comment". 
Overall, the vote on the code's provisions had been "very positive" (approval by "90- 
100%"). But a few clauses (six) had not done that well (that is, had been opposed by "20- 
25%" of those voting). He then listed the six and commented on each: 

1.12, - 1 think the issue is the SE cannot just delete data 

2.05, - this is just a hunch— in the ballot the phrase "respects diversity" is, in the 

US, a politically loaded phrase[.]— This is evident by one two page critique of 

this clause. [The commentator from Texas had made his point] 

6.03 ["Support followers of this code"]. Many uncertain votes (rather than 

oppose) put this in the 75% range— no[t] sure what the problem is. 

6.07 ["Only accept appropriate remuneration"]. There is a problem with this, we 
mightjustdropit. 

7.02 ["Review others work only with their consent"]. No idea what is wrong. 

7.08 ["Not undermine another software engineer's job prospects for one's own 
personal gain"]. We need to make clear that this does not mle out appropriate 
competition. We thought the word "undermine" would carry that weight. 

What is remarkable about the provisions in trouble (apart from their consisting entirely of 
clauses added since Version 1 or much revised since then) is how few there are. Support 
for most of the code was overwhelming. 

The problem, if there was a problem, seemed to be the form of the code. The chief 
problem was size. The most silly comment on size was, "Too long, too wordy. Can't be 
written on the back of an envelope." (Why would anyone want to write a code of ethics 
on the back of an envelope?) But there were more sensible versions of this objection, for 
example, one suggesting "a goal of reducing the code size to 40% of the draft size!" 
Some of those suggesting a shorter code seemed to do so because they thought much of 
the content was not about "ethics"— or, as one commentator put it: "Just because 
someone thinks it's a good idea does not make it an appropriate item for a code of 
ethics." Gotterbam had a suggestion for dealing with this sort of comment without giving 
up anything: follow "the ACM model" by taking "the Eight keyword Principles and 
expand them by a word or three so that they could stand on their own" and attach "the 
clauses under each principle as 'explanatory detail', 'guidelines', 'specifications :-)'— we 
need a good word here." It would then be possible to print the code "in a short version, 
when necessary" and still "carry the sense of the whole document."^^ Having done that. 
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"why not call the document: Code of Software Engineering Ethics and Professional 
Practices[?]" After urging the task force to read the comments, especially those that "may 
seem ludicrous", and to suggest language to deal with them, he quoted his favorite 
comment on Version 3's size: "My initial reaction was 'major overkill', but I was wrong. 
I like it! I might even call myself a software engineer!" Gotterbam sent the email through 
the listserv late in the afternoon of November 20. 

10.4 How long, Lord, how long? 

The cover memo to this November 20 email had a "PS" (in capitals): "Please do 
not use the list address for personal correspondence!!!!" The PS seems to have been a 
response to an email exchange that had begun, eariy that morning, when Mechler had 
sent the listserv a one-word message "Test". An hour later, Manny Norman had 
responded (through the listserv): "In case you want to know— test received!" Five 
minutes later, he again used the listserv to announce: "By the way, I am receiving two 
copies of everything you send me. You may have me down twice in the database 
[because he had two addresses]." Norman then instructed the listserv to use his preferred 
address. Almost two hours later, Mechler responded (using the listserv): "First it was a 
test of the site; I think it was done this morning. Second, you must be on the site twice if 
you get more than one; I sent it to the site only. How have you been? Haven't heard from 
you for a while." Norman responded an hour later that he was being kept busy "juggling 
between performing OpenVMS system administration and programming, learning how to 
do same with NT, and teaching C-I~l-," adding that sometimes "I even go home! No rest 
for the wicked. How's yourself." Apparently, what began as a test of the listserv had 
unintentionally turned into a personal conversation broadcast to the entire listserv 
(because a "Reply" to the listserv functioned as a "Reply All"). 

The Mechler-Norman conversation seems to have had effects beyond 
Gotterbam' s postscript. Early next morning (November 21), Mark Kanko wrote the 
listserv— with the subject heading "Re: test": "Someone please remove me from this mail 
group." Even earlier that day, Tom Jewett had written Mechler and Norman (with a copy 
to Gotterbam) with the same subject heading as Kanko: 

This is a large listserv, and as much as I'd like to meet everyone on it and be able 
to visit electronically, my inbox overfloweth even without multiple copies or test 
messages and personal comments that aren't meant for me. (Please note that this 
is NOT going to the listserv.)^^ 

About 9:05 AM, Mechler iesp)nded directly to Jewett (with copes to Norman and 
Gotterbam), "Sony we inadvertently hit the reply and slowed down the large amount of 
traffic on the list" He then explained that he "was sending a test over and over because 
n^^ e-niailtept coning back [observing that, thanks to Jevvett's response, he knew that at 
least one person got the test] ."^ ^ 

An hour later Mechler wrote the listserv again, this time on official business, 
though with the salutation 'Don". Mechler had not yet read "all of the attached 
comments" but already wondered "with such a high rating for the present form v\^ 
change it now?" Changes meant "all the reviews again". Would it not mate more sense 
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just to work on those provisions that received "negative responses"? Mechler was here 
exhibiting "engineering conservatism" (sometimes crudely summarized, "Don't fix what 
ain't broke"). But he was also identifying a deeper problem with the SEEPP process as it 
had developed since Melford's departure almost a year ago. 

Until Melford left SEEPP had tried (however unsuccessfully) to follow its 
"Guide to Operations" .^^ The Guide had a well-defined process for devdopng 
"standards" (by v\Mch the Guide meant nies vrntben, lite the code, with "shall") . The 
working group's chair was (according to the Guide 4.1.3 and 4.1.4), to use "as 
expeditious a method as needed to establish the WG membership's consensus" on 
v\teher "the conqieted draft can subsequently serve as the foundation for an iterative 
process of refinement" The worldng group did not have to agree with every pait of the 
document or even be willing to have it adopted in its present form. All they had to agree 
on was that the document was good enough to work with. Mechler had done that with his 
"sub group" for Version 1. While Gotterbam had implicitly agreed with Mechler's group 
that Version 1 could serve as a working draft with Version 2.1 Gotterbam achieved 
consensus again within his own working group (by then, also the task force). 

Once there was consensus that a document could serve as the basis for drafting an 
acceptable standard, the next step was to enlarge the working group into a "balloting 
group". A balloting group had to have "balance" (that is, "[avoid] dominance by any 
single interest category "). The balloting group obtained balance by adding to the 
working group "all other appropriate individuals and organizational representatives." 
(Guide 4.3) The ballot put before this group was to have three choices: Approve, Do not 
Approve, and Abstain. Any negative vote was to "be accompanied by specific reasons in 
sufficient detail so that the specific wording of the changes that will cause the negative 
voter to change his or her vote to 'approve' can readily be determined." If the changes 
are made, then the vote "automatically becomes affirmative." In the absence of reasons 
for a negative vote, the ballot "shall, after a follow-up inquiry, be classified as 'no 
response.'" An Abstain counts (more or less) as a "no response". At least three-quarters 
of the ballots must be returned (abstentions counting as returns), but more than thirty 
percent abstentions invalidates the balloting. The worldng group was then to resolve as 
marry of the negative votes as possible (by accepting the changes proposed). Those that 
could not be resolved, "together with the reasons of the negative voter and the rebuttal by 
the WG members conducting the resolution of the ballots, shall be submitted to tte 
balloting group, providing each men±)er an opportunity to change his or her ballot" The 
Guide even recognizes that "[further] resolution efforts may be required if additional 
negative votes result" The Guide' s process puts the pressure on the irdividuals otgecting 
to find a way to agree. Where "a significant number" of individuals continue to otgect to 
some provision, the task force may recommend the standard for "trial-use", that is, for 
tenpjrary adoption to see whether it can prove itself in practice. (Guide 4.3.6) Every step 
had a deadline. There was no endless recycling. 

Gotterbam did not answer Mechler's question ("why change now?"). Instead, an 
hour after Mechler posed it Gotterbam resporried to "Ed arid every body else" (using the 
listserv) that the question indicated that "my request to you all may not have been clear". 
So, Gotterbam is not "broadcasting my reply" (a frown sign following, indicating 
unh^Dpaness, v\tether with having to write again, or with the exchanges earlier in the day 
about using the listserv for messages directed to individuals, or perh^DS both). Admitting 
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(once again) that yesterday's email (the collection of responses) was "VERY large", he 
tried "briefly" to clarify his request (the one in the cover memo). He wanted responses 
from "industry folk" identified as such. He wanted everyone to read the comments 
(noting that not every clause received comment). If a comment seems "on the mark" (and 
only then), "indicate how you agree with the comment" and also "suggest some re- 
phrasing". He also wanted everyone to look over the Principles to see "if we can make 
SLIGHT modifications to them" to pick up anything important in their subsidiary clauses 
(so that they can "stand alone" and still "convey the sense of the code"). If "we could do 
this then we could both keep the Code as a whole— Principles and Clauses[— ] and print 
the Principles on the back of a society's membership card! :-)." After again urging 
members of the listserv "not to Broadcast letters that are intended for individuals", he 
concluded, "We are in home stretch and the results are very positive! !" 

While Gotterbam was waiting for his task force to respond, comments and ballots 
continued to come in. Perhaps the most unusual of these late arrivals was from the 
Planning and Architecture Office of St. Paul Companies (of St. Paul, Minnesota). 
Beginning with a very business-like "Sir", the email indicated that St. Paul "would like to 
adopt the ACM/IEEE code for our internal use." St. Paul had "modified it slightly to 
generalize the language beyond systems engineers." The writer wanted to know what sort 
of "source reference or citation would be appropriate". St. Paul had already been working 
on an internal code when it saw Version 3. Its code would gain "considerable additional 
strength when backed by these two prestigious societies", but it had found Version 3's 
wording "cumbersome for employees who are not [in] a consulting arrangement, and for 
IT staff that are not doing systems engineering". He would send Gotterbam the 
"'modified' draft" with the revisions clearly marked.^^ 

Thus began GotberiDam's first experiment with introducing the code into a 
business environment He lespjnded "yes" (or "of course") to St Paul's request for 
peranssiorL When he contacted St Paul's months later, he learned that the conpariy "had 
only incorporated sections of the code into [its final document]." This was a success 
conparedto some con^Miies he dealt with later. There seemed to be two m^or blocks to 
a conpary just adopting the code as its owa One is (v\tot Gotterbam came to call) "the 
dinosaurs problem". A con^Briy officer v\to originally wanted to have the conqsry 
adopt the code for its software engineers would eventually report back that the conpary 
could not "officially adopt the code" because "getting it through their bureaucracy" 
would be "too much of a hassle". (The "bureaucracy" made the conpariy a "dinosaur^' 
unable to ad^ to a new environment) The other problem was corporate counsel. Often 
the con^Briy's lawyer would block adoption because the conpariy should not be 
"supporting one professional society rather than another." The corporation should be 
neiiral between professional societies; and adopting one code rather than another (even if 
the codes covered different activities) might constitute support One corporate lawyer 
raised an even odder otgection. The con^Miy could not publicly adopt the code. The 
company in question manufactured computers and had a policy against revealing the 
source of parts used in constructing its computers. The lawyer thought that the same 
policy should apply to the source of the company ethics policy. The company could adopt 
the code, but they could not publicly admit to having adopted it.^^ 

For ten days, no one on tte task force responded to Gotterbam' s Noven±)er 21 
email— and no one else responded to the November 20 email either. Thea on Decen±)er 
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2, Gotterbam received two responses, one from Fairweather in England, the other from 
Weckert who, "still in Spain" (rather than at home in Australia), was (he apologized) in 
no position to get responses from industry. Both emails were long (six to seven pages). 
Weckert's response was all detail. He seemed to have gone through Gotterbam's 
collection of comments, cutting out those he wanted to respond to, pasting them in his 
email, and then inserting his response in caps. A typical response would be, "Perhaps, but 
I'm not sure where it should be" (in response to a suggestion that the terms 'public', 
'employer', 'client', and 'user' be clarified). 

Fairweather' s introductory sentence nicely sets the stage for the comments that 
follow: "My overall feeling is that if we are getting the high levels of approval that we 
are, we should 1) be wary of making changes that some who currently approve of the 
code might disapprove of; 2) be wary of major new developments such as stating the 
principles in a 'stand alone' manner." There followed pages of detailed response to 
particular changes Gotterbam (or, more often, one of the respondents) had suggested. Of 
special concern to Fairweather was the short version of the code Gotterbam had 
suggested. While wary of it, he thought it "would be OK **provided** we make it clear 
that they [the Principles standing alone] are only extracted from the full code, and should 
never be used on their own, or quoted without a reminder that they are extracted from the 
full code." Fairweather even took the trouble to suggest the form in which he thought the 
extracted Principles should be printed. Of special importance to him was that the in- 
particular clause not be omitted. The presence of an in- particular clause for each Principle 
would make clear that the Principle could not really stand by itself. 

10.5 Three days in Baltimore 

Gotterbam was now making final preparations for a meeting with the other two 
members of his executive committee to revise Version 3 (or, as he now admitted, "build 
Version 4"). The meeting would be in Baltimore. An important step in those preparations 
was incorporating into the comment document all comments that had arrived since 
November 20. That work was completed by December 1 (the day before the Fairweather 
and Weckert emails arrived) .^^ The final summary, though a few pages longer, contained 
nothing strikingly new. The comments had become predictalie. 

By Decomber 3, Gotterbam had two other documents ready. One was the final 
tally of ballots. Using Excel, Gotterbam was able not only to tally the votes, but to 
calculate percentage in favor and opposed to each clause. Overall, the mean ^Dproval had 
been just over 94% and the mean disapproval just over 3% (with the difference in 
uncertain votes) .^* Four clauses (1.10, 1.11, 3.02, and 3.03) received unanimous support; 
and one more (3.06) passed without ariy votes opposed Software engineers seerried to 
have no doubt that they should promote the privacy of individuals (1.10), use data 
legitimately (1.11), only sign documents within their responsitality (3.02), and rgect 
bribery (3.03), and were only slightly less certain that they should disclose conflicts of 
interest (3.06). 

Having conpleted the tally of ballots, Gotterbam could prepare v\tot he jokingly 
called, "VersiorL3b mod-notkin, et al").^^ This was the Version 3 that the executive 
committee would work from The first two lines, inserted above the title (in large print, 
bold, italics, and underlined), explained the format: "This has some of the modifications 
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[to consider] and clauses in bold have less than a 90 [%] favor rating." Twenty clauses 
were in bold (a quarter of the Code's eighty clauses) .^^ Bdowthis heading (in bold) was 
the new title of the code ("Software Engineering Code of Ethics and Professional 
Practices") and, immediately below that, the same title again This was the first of the 
"modifications" already incorporated Next in bold was a question, 'Does this footnote 
get attached to the CODE?" Tlie footnote, listing the codes "refened to", had, until then, 
been part of the article introducing the code. Why Gotterbam thought it should be pait of 
the code is unclear. No one v\to commented on Version 3 had suggested it should be and, 
of course, footnotes of that sort are rare in codes of ethics. (Indeed, I know of no code 
that has a footnote listing source codes.) Here perh^:s the scholar had gotten the better of 
the draftsman (The footnote did not survive Version 3b.) 

All the modifications seem to be responses to NotkirL^ ' The first (in caps) is just 
under the title "Preamble": 'Told Notkin that this was going in the Preamble— v\tere." 
"This" consists of two sentences: 

Software engineering is unique in the amount of time spent in maintaining and 
modifying existing software. The flexihality and malidility [sic] of software 
systems places [sic] special burdens on the software engineer to treat software 
modifications with the same professionalism as new devdopment 

The first paragr^ has two places v\tere "and maintenance" (in italics) has been inserted 
after "devdopment", with other changes that Gotterbam had promised Notkin scattered 
here and there. The largest of these was in 6.13: "Share useful software-rdated 
knov\dedge, irwentions, or discoveries with the profession, for exanqie, by presenting 
p^:ers at professional meetings, by publishing articles in the technical press, and by 
serving on the profession's standard-setting bodies, provided this does not violate 
confidentiality, or cause loss of trade secrets, or cause competitive disadvantage (see 
4.05)." (This clause— without the addition indicated by italics— had received an 89% 
favorable vote, just under the 90% cut off.) There is only one surprise. Just above clause 
3.07 ("Refuse to participate...") Gotterbam wrote (mostly in caps), "Early retums had 
some objections to this/now sits at 95% positive! Told Notkin it was gone. Ooops." 

There is a lesson here. Notkin had (rightly) said that he spoke for himself. He had 
made a prediction about what his technical council would do, but seems to have badly 
misjudged it. In fact, the council seems not to have cared enough one way or another to 
respond. Notkin had never had to test his own ideas in open debate. He had supposed that 
he spoke "common sense" (and Gotterbam had thought so too). But the December tally at 
least suggested that common sense may not have been what Notkin supposed. Leaders 
generally suppose they know what "the profession thinks". This was, it seems, what 
Shaw and Frailey thought too. They might have been right— but, in fact, they were, it 
seems, largely wrong. There are nonetheless at least two reasons to take the views of 
leaders into account. One is that they may have a better understanding of the issues than 
their followers; another is that they may have the power to block a code even if they are 
wrong in their views, dogmatic, and dense. The first reason is always worth considering; 
the second, something to get around if possible, for example, by taking a vote that reveals 
how wrong the leader is in a way not easily dismissed. Gotterbam would have done well 
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to promise Notkin less, especially since he did not (it seems) send his official response to 
Notkin until most of the ballots were in and tallied. 

The next day (December 4), Gotterbam, Miller, and Rogerson met briefly in the 
lobby of the Brookshire Hotel in Baltimore. It was late afternoon. All of them were tired 
after traveling most of the day. Each had a laptop computer with him. Gotterbam 
distributed copies of the documents he had prepared (the tally of votes, the final 
collection of comments, Version 3b, and the emails from Weckert and Fairweather). 
Some of these were on a diskette; others on paper. After some discussion of large issues, 
division of labor, and timetable for the next three days, the three agreed to meet again in 
Gotterbam's room early the next morning, adjourned to dinner, and retired early. 

The meeting's location was not arbitrary. Gotterbam had chosen Baltimore 
because traveling there was relatively easy for all three, because its hotels were relatively 
inexpensive, and because each would be far from the distractions of home. Gotterbam 
had chosen the Brookshire because it had all the conveniences of the city close by, was 
not too expensive, and had two- room suites. The outer room of the standard Berkshire 
suite had a work table (or large desk)— as well as the usual couch and comfortable chairs. 
Only Gotterbam's choice of meeting room was arbitrary. Miller and Rogerson each had a 
similar suite down the hall from Gotterbam's.^^ 

The three (as agreed) met in Gotterbam's suite after breakfast. They were to go 
through Version 3b once, making such changes as the comments or tally suggested; then 
to go through the revised document, making sure that it said v\tot it should and, v\ten it 
did not revising accordingly; and so on until they were satisfied Nothing was immune 
from inpDvement Once work on the code was conqiete, they would draft two letters: 
one to the task force exjiaining v\tot they had done; the other, to the Steering Q)nm 
asking it to recommend Version 4 to the two societies for ^Dproval. Gottedem expected 
the work to tate two full days. In fact, it took much of two evenings as well— and much 
of the third day's morning. Rogerson, v\to volunteered to be the recording secretary, sat 
at the table. Sometimes GotteriDam and Miller sat at the table too, looking at a p^:er copy 
of this or that document or amending their own p^:er copy of Version 3 v\ten they hoi 
agreed to a change. Among the pie of p^:ers on tte desk was one containing comments 
(and ballots) that had been faxed These (unlite the emailed comments) were generally 
short (and handwritten).^^ Sometimes, though, Gottedem and Miller stood behind 
Rogerson, looking at v\tot he was typing, or took turns pacing the oblong room, sitting on 
the couch or in one of the chairs. Though the room had a hag window at one of its short 
ends, little day light came in. (Gotterbam had pulled the dr^:es to mate reading the 
corrpiter screen easier.) Discussion was almost continuous. As Miller recalls. 

Several times we got into deep discussions about the wording of a clause. I think 
all three of us f dt that v\tet we were doing might have significance beyond v\tot 
usually occurs in academic scholarship. We wanted to agree to something (to get 
it "out the door"), but we wanted to get it right Some of the suggestions we had 
gotten about the code made it clear that every word counted — there were shades 
of meaning in v\tot might otherwise be considered trivial word changes.* ° 

Qn the first day, Gotterbam put off lunch until the middle of the afternoon saying 
over and over, "We' re making progress. Let s just finish this first run through, then go to 
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lunch." Gotterbam treated toilet breaks in the same way— until Miller revolted, declaring 
he was going "now" no matter what. Only when keeping track of changes to their paper 
copies of the code became too hard did Gotterbam agree to lunch, and then only on 
condition that they stop at a copy shop to have the code's electronic version put on paper. 
Having eaten a quick lunch, they found a Kinko's. Kinko's copiers had only recently 
been put on a network that allowed printing from a diskette. The first attempt to print 
failed. The staff, well-groomed clerks in their early twenties, were not sure what was 
wrong. SEEPP's executive committee, with no time to waste, volunteered to fix the 
problem. The staff hesitated, perhaps worried what the three, all obviously survivals from 
the pre-electronic age, might do to their sophisticated system. Reason, firm looks, claims 
of expertise, and a few well-placed technical observations won out, however, and the 
three software engineers were soon checking wires and adjusting settings until they 
identified the problem, a cable that had come unplugged. The network fixed, they quickly 
printed three copies of the nascent Version 4.0 and returned to their work at the 
Brookshire. Miller thought it "was somehow fitting that we old geeks figured out what 
was wrong at Kinko's. We were going to get that code finished no matter what!"'^^ 

Dinner, though quite late, was pleasant The three had a first draft of Version 4. 
The end was in sight Tomorrow they would work on the details. Next day, they worted 
much as they had the day before— but v\ten they went to dinner that evening, they had 
eveiything they had hoped for in the code. The next niorning they ranpleted v^ 
two letters. By noon of December 7, the meeting was over. Ttey had chected out and 
were on the way to the airport Reflecting on v\tot they had done, Gotterbam observed, 
'The most effective way to do it [this sort of m^or revision] was NOT by email from 
separate distracting environments. Face to face— mind to mind— worldng in the same 
direction gets the worlc done much better and more efficiently."*^ The three days in 
Baltimore had had much the same fed as those months at DeMontfort Gotterbam was 
(as he put it) "in his glory" during those three days, but for several years afterward Miller 
(with a smile) refened to Gottedem as "the taskmaster".* ^ Such is the price of glory. 

Gotterbam flew out of Baltimore early in the afternoon of December 7, getting 
home quite late. The next morning (December 8) was the beginning of exam week. He 
had tests to give and projects to grade. Almost the first thing he did that morning was to 
send the task force Version 4.0, with the cover memo (signed "don") that the executive 
committee had prepared the day before. After declaring that "the results of several emails 
and a three day meeting by tte executive committee" were "below", Gotterbam noted, 
"We need to send tiie FINAL COPY OF THE CODE BY MONDAY DECEMBER 15." 
He was asking the task force to "give this one more review". The "substance of the code" 
was unchanged, but "we did clear up several things and restmcture it" He then 
summarized v\tot the executive committee had done. First they had "modified the 
Principles so that they can stand alone as a reminder of the ertire code". The short 
version now stood before the main code. Second, they had shortened the Preamble, but 
"also included issues of maintenance", and had tried to mate it clearer "v\ten resolving 
ethical tension that the public interest is paramount'. Third, they had re-ordered the 
principles, putting "the PUBLIC first v\tere it belongs". Fourth, they had reordered the 
clauses "in general putting the more asprational elements first and the more specific 
items later^'. Last ttey "clarified the function of the code by renaming it'. Gotterbam 
concluded by again pleading for "your comments" . 
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Though this summary of changes makes it clear that Version 4.0 differed 
substantially from Version 3.0, it in fact substantially understates the differences in at 
least five ways. First the executive committee had shortened the Preamble, in large part, 
by deleting Version 3's second and third paragraphs. All references to "three levels of 
ethical obligation" were gone. Comments had shown that the distinction confused rather 
than clarified. The idea of a code as consisting of "aspirations", "expectations", and 
"demands" had (at least officially) been abandoned.^'^ Whatever its theoretical value, the 
distinction had no practical value within a code. As Gotbeibam explained years laten 

In version 3 1 had tried to med; some of the olgections we had heard early from 
the steering committee- v\tot makes this a SE Code of ethics v\ten it says some 
things said ty other profession's codes? So the prearrdie contained comments on 
three levels of ethics— common human virtues, professional ethics having due 
care, and specific professional ethics related to a particular domairL It was this 
latter part that made it an SE code. Anyway, this distinction caused confusion 
because people reading the preamble expected to find each clause clearly labeled 
as to v\Mch of these three levels it was on We knew that ariy attend to deal 
with this type of [otgection ty] dividing the Code would have landed it in a mire 
of debate about v\Mch clause belonged v\tere and would have distracted from the 
intent of the Code. One of the good things we did at that meeting was to scr^n^^ 
three-level shjff. 

What the executive commitiee meant hy re-ordering the clauses so that the "more 
asprational" ones come earlier is not clear. In v\tot way, for exanple, is 1.01 ("Accept 
full responsrtality for their own acts") more asprational thcffi 1.08 ("Volunteer 
professional skills to good causes...")? Is this another exanple of the concept of 
"aspration" doing no work? 

Second, the executive committee had not limited changes in the Code to clauses 
with a relatively high percentage of opponents. They had in fact made many small 
changes in clauses with very high ^Dproval ratings. For exanple, they had replaced 
"enployee" with "software engineer" in both old 5.01 and 5.02 (new 5.02 and 5.03). 
Both clauses had been ^proved ty more than 95% of those voting. 

Third, the executive committee had also made larger revisions in clauses with 
equally great (or greater) support The most dramatic of these revisions is the new 4.04 
('Do not engage in deceptive financial practices such as bribery, secret payments and 
double Mling"). This clause replaced three clauses in Version 3: 3.03 ("Reject bribery"); 
3.04 ("Accept no payback, kickback, or other payment from a third party to a contract 
except with the knowledge and consent of all parties to the contract"); and 3.05 ("Accept 
payment from only one party for any particular project or for services specific to that 
project except when the circumstances have been fully disclosed to parties concerned 
and they have given their informed consent). Clause 3.03 had a 100% approval; 3.04, 
98%. Only 3.05 (at 89%) had failed to achieve the 90% that (in Version 3b) declared 
would mark a clause for revision. 

Fourth, while this one revision may seem to explain the drop in number of clauses 
from 80 to 78, it in fact does not. Several other clauses had entirely disappeared (such as 
old 2.03 "Affix their signature only..." or old 7.08 "Not undermine another software 
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engineer's job prospects.. .).^^ Othens (unrelated) had replaced thera for exanple, new 
3.15 ('Treat software maintenance with the same professionalism as new development"), 
inspired by Nofkin, or new 5.12 ('TSTot punish aiiyone for expressing ethical concerns 
about a project"), v\Mch, though reasonable, does not seem to have come out of the 
comments at aU. 

Frfth, Version 4 was about four-fifths as long as Version 3.*^ The change is 
actually greater than this fraction suggests. After all, the one-fifth reduction was achieved 
vMle adding the (largely redundant) Short Version (189 words). Without the Short 
Version, Version 4 would have been just under three-fourths the length of its immediate 
predecessor (though still almost twice the length of Versionl). A reduction in length of 
one quarter, especially v\ten comtaned with the addition of new clauses, is independent 
testimory to tte scale of revision acconqiished in the first week of December. Version 4 
is almost a new code. 

The executive committee had, it seemed, not fdt at all bound ty the poll of ACM 
and lEEE-CS members, ty the drafting principle "Leave well enough alone", or ty 
Mechler^s concern that making ariy but minor changes in Version 3 would bring on 
another poll, putting off adoption for many more months (and therety chancing a wreck 
on shoals alr^dy perilously close). Whatever irrpDvements the executive committee had 
made (and there were many), they came (as the committee should have learned from the 
large dissent on "diversity") with the risk that wtet. they thought uncontroversial 
uipDvements might prove quite controversial. They were, in effect, gambling the 
overwhelming support the Code had achieved 

Re-ordering the Principles and the Clauses under each Principle also had the 
effect of making tracking changes, and con^Bring changes and votes, much harder for 
anyone v\to tried (including the executive committee). That effect, though doubtless 
unintended, is worth noting, especially since there was not much reason to reorder the 
Principles (only one commentator suggested it) and no reason to reorder the Clauses 
(since no commentator had suggested that). Even someone v\to lited the re-ordering 
might conqiain about that effect For exanple, Fairweather wrote that the "[re-ordering} 
was good, but in the process it becomes more difficult to spot v\Mch clauses have been 
deleted, and some of the ones deleted, I fed, ARE inportant" * ' 

10.6 First comments on Version 4 

Gotierbam had asted for comments when he sent Version 4 to the task force on 
December 8. The first comments to arrive were mine (on Decen±)er 9), a three-page fax 
(not counting the cover) .*^ My "overall comment" set the tone for the particulars that 
followed: "very soon, it [the code] should be gone over ty a good editor." To soften the 
in^ied critidsm, I added in explanation: "Committees have a tendency to garble text, to 
introduce unnecessarily clumsy modes of expression, and otherwise to mate the code 
more difficult to use than need be." The comments that followed this explanation were (I 
said) intended as illustrations of v\tot I had in mind; n^^ silence on substantive issues 
indicated only "n^^ virtually conplete satisfaction with the Code's substance". I said 
nothing about the reordering of the Prindples or clauses because, though I disapproved, I 
regarded order as a matter of taste. There are many ways to order a code. If the liMy 
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users could not see the advantages of the order I chose, they were welcome to anything 
they thought better. 

My objections were of another sort. The revisions had introduced what in 
software are called "bugs", at least three kinds of them. First I had found a great number 
of simple errors (typos)— indicating nothing more than haste. For example, consider my 
suggestions (given in brackets) for the last three lines of the Preamble's fourth paragraph: 
"In these judgments concerns [delete s] for the health, safety, and welfare of the public is 
the primary concern... . That is [insert ,] the 'Public Interest' is central to this Code." 

Second, I had noticed sloppy drafting. The first instance (occurring both in the 
short version's introduction and in the corresponding sentences in the long version's 
Preamble), was a "transition from 'must' [in the first sentence] to 'shall' [later in the 
paragraph]". Whatever the point of the transition, it is (I said) "too subtle for me". I 
therefore recommended "using 'shall' in both (since 'must' sounds too much like banging 
on the table)." Changing terms without a clear change in meaning invites confusion. Does 
the change mean something? What? (The next edition of Version 4, and all Versions 5, 
followed my suggestion in the Short Version but not in the Preamble.) 

I also found several places where, though there was no risk of confusion, there 
seemed to be unnecessary redundancy. For example, I suggested revising the last 
sentence of the Preamble's fourth paragraph ("That is[,] the 'Public Interest' is central to 
this Code"): "delete this entire last sentence as entirely redundant, enough [in the 
sentence before] to say the public health, safety, and welfare are primary." This 
suggestion was not taken. 

Third, Version 4 seemed to have introduced a number of conceptual problems. 
Consider, for example, the new 4.04 ("Do not engage in deceptive financial practices 
such as bribery, secret payments and double billing"): "Is bribery a 'deceptive financial 
practice'? [I asked] What if the bribery is open?" It might be better to say, "not engage in 
bribery, double billing, or other improper financial practices." I had, I added, "[omitted] 
'secret payments' since some— for example, those involving national security— might not 
be improper."^^ 

Another one of these conceptual problems was in new Principle 1. It now read, 
"SofbA/aie engineers shall always act in the public interest..." I suggested that it was 
enough if they always acted in ways "consistent with" the public interest 'To require 
them always to act 'in the public interest is to fortad them to do good for themselves, 
their clients or enqioyers, and even customers v\ten doing that is neutral with respect to 
the public interest" Surely, that was not v\tot was intended Indeed, that suggestion 
would be inconsistent with Principle 2 ("Software engineers shall act in the best interests 
of the client or enqioyer within tte confines of the public interest") .^ ° 

Gotterbam seems to have received only one other response from the task force 
before Version 4 was due at the Steering Committee. That one, ty direct email, was from 
Ben Fairweather— lite me, a philosopher, not a software engineer. What he wrote was, as 
he put it merely 'TMHO" (in n^^ humble oprdon); it was almost entirely substantive. 
Apparently, Fairweather had not only read through the document carefully, he had, 
despite the difficulty re-ordering introduced, systematically conpared each provision of 
Version 4.0 with the corresponding item in Version 3.0. He had much to say about 
Version 4.0, some negative but much of it positive. Quickly, without comment 
Gotterbam forwarded Fairweather' s email to tte listserv.^' Later that day, Rogerson 
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(Fairweather's boss) replied directly to Gotterbam, with a copy to Miller. A few hours 
later, Miller also responded.^^ Miller seemed a hat gnmqy. His "initial reaction to all 
these comments" was that "we cannot do this forever, tiying to please everyone over and 
over." Having made that point, he relented: "if we can QUICKLY come to some 
language that is a clear irrpovement on our already irrpoved language, so be it" Miller 
did not have much to add, but what there was was inserted below the relevant part of the 
Fairweather-Rogerson exchange he had pasted into his email. The Fairweather-Rogerson- 
Mller exchange offers more insight into how the executive committee now ^Dproached 
the comments they were receiving. 

Fairweather^ s positive comments showed the care he had given Version 4. Many 
were of the form "InpDved" (after quoting the new Principle 1 in full); or (after quoting 
2.01) "An inpDvement on the old 4.01"; or most often (after quoting the new 2.04) "A 
mild inpDvement on the old 4.02". But some of the positive comments were more 
conqiex (and mix in criticism); for exanqie, Fairweather admitted that the new Principle 
3 ("Software engineers shall ensure that their products and related modifications are of 
the highest professional standards possible....") has been inproved by the "removal of 
detail" but adds, that 'loss of mention of products being 'acc^table' to the errqioyer, the 
client, the user, and the public creates a deficiency with the code: it should have a clause 
[requiring acceptalility]." " Rogerson's response was, 'If they are of the highest 
professional standards, then by inference they will be acceptable as this is part of the 
definition of professionalism" Then, perii^:s realizing the risks of relying on inferences 
from a definition of "professionalism" not given in the code (and periiaps controversial), 
Rogerson relented, "An extra clause (or addition to an existing clause) is worth doing." 
Miller disagreed "violertly": 

If you want yet another clause, fine. I might point out, however, that you can 
worlc to the highest standards and still have some idiot not "accept" your work 
Part of being a professional is knowing when to adhere to standards v\ten idiots 
demand something else. 

A good point, but one that admits the possiMity that "the highest [professional] 
standards" might be too high for public, customer, or user (unless "possible" means 
something lite "practical" rather than "technically possible"). The more detailed 
language of Version 1, v\Mch survived more or less through Version 3, avoided this 
problem "Software engineers shall, insofar as possible, assure that the software on v\Mch 
they worlc is useful to the public, the enployer, the client, and the user, conqieted on 
time and at reasonable cost, and free of significant error" Aryone v\to did not find 
acceptable a product that was useful in this wcy, conpletedatreasonafciecost, and free of 
significant error would, indeed, be an "idiot'. The new Principle 3 was not changed 

The most negative of Fairweather's comments concerned the newest part of the 
code: "I cannot accept this short version as it stands. If it is not modified, I will have to 
ask for rr^^ name to be removed [from the list of SEEPP men±)ers at the end of the 
code] ." Fairweather then explained why he was unh^Dpy (in effect, summarizing v\tot he 
had written on December 2): "the lack of warning not to treat this short version as a 
conqiete code of ethics is a fatal flaw." (10.4) The flaw was, however, easy to remedy, 
just "add a line that it is not the conqiete code, and is only an 'aide memoire' for the full 
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version, which itself is not intended to be used so that individual parts in isolation could 
justify errors of omission or commission." Rogerson's comment was that "Ben's concern 
is valid". He suggested adding a sentence that "points people to the full code and explains 
the importance of the clauses."^'^ Miller agreed and even suggested a paragi^ii that 
(without amendment) became the first paragr^±i of the short version of the next edition 
of Version 4." 

Fairweathei^s negative comments did not always receive such favorable 
treatment Consider, for exanqie, the discussion of 8.08 ("Encourage colleagues to 
adhere to this Code"). Fairweafher otgected that it "doesn't ^Dpear to me to be suitable for 
the 'self principle" (and suggested going back to old 8.08 with a small revision). 
Recalling that I too had suggested that 8.08 belonged elsewhere (under Principle 6 
Profession), Rogerson recommended instead that 8.08 be revised to read, "Consider 
violations of this code inconsislent with being a professional software engineer." Miller^ s 
response was, "I don' t care." The next version of 4 adopted Rogerson' s suggestiorL 

Rogerson was not always this accommodating, however. For exanple, 
Fairweafher otgected to the rewriting of Principle 5. The principle, vMle inpDved, had 
(Fairweafher noted) lost "1) acting fairly (in gmeral) and 2) 'enable and encourage those 
who they lead to meet their own and collective obligations, including those under this 
code' ." Judging that loss to be "severely detrimental", he recommended adding "a new 
5.01 [for acting fairly] and 5.02 [for enabling]." 'TSTot corvinced— leave as it is", was all 
Rogerson had to say. Miller agreed: "Yes, leave as is." It remained as it was. 

Occasionally, Miller was quite dismissive. Fairweafher thought it "detrimental" to 
delete from old 2.01 (now new 1.04) the words "or merely know" after "reasonably 
believe". Fairweafher would accept deleting "merely". Rogerson replied that he thought 
"believe" includes "know" in this context (1.04 read: 'T)isclose to ^Dpropriate persons or 
authorities any actual or potential danger to user, the public, or the environment that they 
reasonably believe to be associated with software or documents.") Miller responded 
directly to Fairweafher (though Fairweafher was not among the email's addressees and 
probably never saw the response): "Put a cork in it Ben What we have here is good" 
Clause 1.04 was not amended 

Over the weetend, Gotterbam revised Version 4 (v\Mle also grading exams). 
Monday afternoon, December 15, he emailed the listserv a one-page memo entitled 
'Version 4.D0NE". The memo maintained the tone set by that title. Gotterbam thanted 
"you all" and described the writing as "an exhilarating experience"— adding that "[v\ten] 
projects come to a successful con5ietion[,] there is nomially a celebration and everyone 
sh^ffis hands ard is proud of the work acconqiished" He expressed the desire to rneet all 
those he had so far only known through email. 'The problem with E-mail is that many of 
you only have a virtual persona for me." Then, getting down to business, he reported, 
"We have received several comments from the task force on Version 4.0." Some were 
positive, some were not so positive; some substantive, some concerned with "issues of 
grammatical preference". "We" had tried to tate them into account in the "final version". 
Some of the lengthy changes might be better in "worted exanples of the Code". 
(Apparently, Gotterbam was here refening to one of Fairweafher^ s suggestions.) He 
would, he said, explain those "worted exarrqies" in a later email. The code was not 
perfect But as in any project "at some point we must call [this one] conqiete even 
though we can still thiric of other inpovements." He had decided now was the time. 
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Hoping the task force approved of what had been done, he noted that his memo was short 
"because I have placed the final version on a web page: http://www-cs.etsu.edu/seeri/ 
secode.htm."^^ (SEERI was now in operatLon) Task force membens should read the code 
"one more time" and be sure to "carefully check the credits at the end of the Code" 
because he wanted "the form of your name and its spelling to be correct and to your 
liking." This version was the one "being sent" to the Steering Committee for adoption by 
both the lEEE-CS and ACM.^ ' 

10.7 Party time 

The next morning (December 16), just before 9:00 AM, Manny Norman wrote the 
listserv (replying to "VERSION 4.D0NE"): 'Thanks, and the season' s greetings to all of 
you. Periicp;, we could figure out some sort of get-together at some mutually acceptable 
geographical location sometime in the New Year." Apparently, Rogenson lited the idea 
He quickly responded: "How about the Christmas Mands?"^^ Duncan Langford soon 
joined the horseplay: "Brilliant idea. Now, have we enough left in Don' s budget to fund 
fares & accommodation...:-) Season's greetings to all!" About 11:00 AM Gottertem 
joined the discussion: "Budget ???? did I miss something?!?!" (Almost everyone v\to 
had anything to do with SEEP? knew by now there was no budget) Having made a jote, 
Gotterbam almost became serious: "There is a splendid conference ETHICOMP '98 in 
Rotterdam in March. The ACM is having an Etlics Conference in Washington in May. 
We can have two parties."^ ^ About the same time next morning, the horseplay began 
again. Mechler wrote, "I never thought e-mail could catch a sigh of relief but the last few 
days emails was [sic] a perfect exanqie." Thea perii^:s thinking this comment was not 
light-hearted enough, he continued, "Isn't it just lite a leader to ask v\tot budget v\ten 
the project is over and everyone wants to celebrate." Mechler wondered how there could 
be an ethics meeting "in Washington????" and wished everyone "trappy Holidays". A 
half hour later, Norman ended v\tot he had started the day before— ly a lispng purt 
"Maybe we should all meet across the Detroit River from me— in Ethics (Essex County, 
Ontario!)." Then, peih^:s thinking he had gone too far with the pun, Norman ^x)logized: 
"I know we're not supposed to be using this listserv for 'flippancy', but I think we have 
reason to celebrate this time."^ ° Everyone must have agreed— or, at least, no one wrote 
the listserv to condemn the exchange. It was, after all, doubly a season to be jolly. 

Before the horseplay was over, Gotteatam sent the Steering Committee— or, 
rather, its chair and vice chair, the official ("final") Version 4 with a cover memo (just 
over two pages long) ! ' Signed 'The Executive Committee of the SEEP Task Force", this 
memo is itself a significant document Not only did it summarize the task force's 
achievements in a way liMy to inpress the Steering Committee as a reason to 
recommend the code to the two societies for ^Dproval, it also announced plans for 
disseminating the code that seem not to depend on v\tether the two societies ^proved. 
The memo made no mention of the Steering Committee's plan to disband at the end of 
the year (a plan about which the Steering Committee had said nothing since September 
and v\Mch the executive committee doubtless hoped had been forgotten) . 

The cover memo's first paragraph offered five (unnumbered) reasons for 
recommending the code for ^Dproval: 
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• Support by both societies will be a public assertion by the profession of a unified 
commitment to ethical responsibility, 

• The Code represents an international standard of practice, 

• The Code has been reviewed and adopted by industry, 

• The Code presents a broad consensus of the profession, and 

• There is wide demonstrated positive support, including from Academia, for the 
Code. 

The next few paragraphs provide detail in support of these claims. For example, to 
explain why the support of the two societies is important, the memo distinguished the 
software engineering code from those of the two societies. The software engineering code 
"addresses the ethical issues and standards of conduct which specifically arise within the 
practice of software engineering." It is not ("[in] this sense") a substitute for any existing 
code. 

While stressing the international participation in the task force ("Europe, Africa, 
Australia, and North America"), the memo also pointed out other ways in which SEEPP 
had avoided too narrow a perspective. The task force had sought "responses from 
members of the major computing societies". It had "received [comments and support] 
from the International Federation of Information Processing (IFIP)."^^ It had even 
included "two lawyers [Barber and Phillips] specializing in conpjter law, and one 
representative from the military [KankD]." (Perhaps wisely, the executive commitbee did 
not mention the participation of three academic philosophers.) 

The executive commitbee also reported an inp:essive response from industry 
(especially inp:essive, given the few months available to obtain it). Several ethics 
officers or ethics directors of "multinational organizations" had reviewed the code 
"positively. . . after sharing it with software engineers in their organizations." Among 
these organizations were 'Lockheed Martin, Northup Grum[m]an, and Digital 
Equipment"" The code had also received support from smaller conpardes: In fact, the 
code had already "been ad^Dbed ty St Paul Conpardes as their information systems code 
of ethics with only minor modifications, such as replacing the expression 'software 
engineer' with 'IS professional' ." 

The executive commitbee then described the "process of continuous review and 
revision" ty v\Mch the final Version 4 had reached the Steering Commitbee. The 
description seems somev\tot garbled On the one hand, the executive commitbee wrote, 
'The final draft of the Code" (that is. Version 3) was published in Computer and CACM 
along with a survey. Most items "had greater than 95 percent support with many at 100 
percent [with the highest level of opposition being 12%]". Then, having described the 
overwhelming support for this "final draft", the executive committee continued, "In the 
light of feedback, the Principles and associated Clauses have been reviewed and modified 
where necessary." That is, the "final draft" was not the final draft. The executive 
committee concluded this description of process with the hopeful (but unsupported) 
statement: "We are confident that if the survey were to be taken again, all Clauses would 
receive an approval rating of over 95%." 

After a brief paragraph demonstrating academic support by "several requests to 
have the Code included in computer ethics and software engineering textbooks" and other 
requests to develop cases based on the code, the executive committee reached its 
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triumphant last paragraph.^'^ The code had "already proven to be a dynarmc and useful 
document", a "model" within at least one con^Miy; both the ACM and lEEE-CS had 
"already recognized that education about their codes of ethics is an inportant issue"; and 
several members of SEEPP are members of committees charged with educating members 
"about their codes of ethics". To support "education about the Code", SEEPP planned "to 
maintain [the code]" on two websites, one at Gotterbam's SEERI and the other at 
Rogerson's CCSR SEEPP would "continue to gather irpjt from the community about 
the Code and develop and share exanqies of using [it]." Con^Miies had "already donated 
case studies related to the Clauses of the Code." It would therefore be good for "the 
profession if both societies endorsed this effort and ^proved the Code." 

SEEPFs executive committee neglected to mention that it had acconplished all 
this vMle delivering the code six days ahefld of the schedule Gotterbam had proposed ten 
months before. The executive committee was also unable to report three more pieces of 
good news Gotterbam would receive just before Christmas (December 22). One was an 
email from a sales manager at Hitachi America's New Y ork City office, a late ballot. The 
sender had voted in support of every provision, but for several provisions seemed not to 
have been satisfied with "SF" (strongly favorable) as a way to express accurately how 
strongly he favored the provision. So, every now and then there was an "x" far to the left 
of "SF". His only comment was that he would also fax his response." 

December 22 seemed to be a day for catching up on correspondence. Earlier in 
the morning, Gotterbam had received an email from Bangalore. The author, v\to worted 
for Siemens Information Systems (India), wanted to know where he could "get a soft 
copy of the draft SE code of ethics V2.1 that you published in SEN 22 (July 1997)". Even 
"plain text" would do. He wanted to mate it available online in his software development 
center for wide drculation."" Why had it taken so long for Version 2.1 to reach India— 
or so long for India to respond? Whatever the answer to that question, Gotterbam could 
now add Asia to the continents participating in drafting the code. 

Then, after dark, Gotterbam received another email from Siemens, this one from 
Germany. Two emails from Siemens in one day? Could that be mere coincidence? The 
email did not answer that question. It was (like the email from Hitachi) a ballot. But the 
German had not bothered to print out the long columns because "I (strongly) favor the 
clauses put forward. I think, the code could be voted on [in] its present form [Version 
3.0]." He nonetheless had several suggestions. One was tiiat "clauses 1.04, 1.07, 1.08, 
1.09, 1.12, and 1.14 should be inspected more closely"." They might be assembled as 
"an ^Dproved collection of methodologies and (possibly augmented) standards." The 
other comment concerned 6.10 ("Obey all laws governing their work ..")." The Gemian 
thought this clause needed clarificatiorL "Is censorship consistent with public welfare?" 
He wondered v\tether the clause could be dropped altogethen "If if s illegal, let the 
govemmenf s lawyers worry about it" He even wondered v\tether v\tot was meant was, 
"You may disobey the law, if obedience is inconsistent ..." 

Gotterbam does not seem to have passed these three emails on to Miller and 
Rogerson Instead, he wrote the two (on Christmas day) with a problem But, before 
stating it, he described some of his recent correspondence. From tte description, we can 
tell some have been lost. "People are," Gotterbam began, "still sending in votes on 3.0." 
One of these, a "vp in Chicago", had passed out the survey to thirteen of his subordinates. 
"He should," Gotterbam thought, "be upset by the results— 6 of the 13 strongly oppose 
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'being responsible for your work'!!!!!" Gotterbam also seems to have responded to the 
correspondent in India. He was (Gotterbam reported) an "Information Systems Manager" 
who had read about the Code "in the July issue of SIGSOFT Newsletter". He wanted to 
distribute the code "to all of his employees :-)". The only version now available ["4.0"] 
was on the SEERI website. That however, was not the problem he wanted help with. The 
problem was "the long, carefully worked out comments I get by email, some as long as 5 
typed pages,— to which we [the executive committee] replied 'we will take these into 
account in the next version early next year'." Gotterbam wondered whether he should 
instead "ignore the emails, or [answer simply] 'your comments will be taken into 
consideration'."^^ 

Miller responded on December 27 (with a copy to Rogenson). It was (he thought) 
inpjrtant that "the people do get a resp)nse".'° He wanted them to fed part of the 
process. But any respjnse could be no more than a response "for the three of us, since we 
have the authority to speak only for ourselves." Miller suggested the respjnse mate four 
points: First, Version 4.0 (in its final form) is now before the IEEE and ACM governing 
bodies and is no longer sutgect to change. (Coiresp)ndents should be sent a copy.) 
Second, "we" should "tell people (and commit ourselves to the project) that we will begin 
woilc on version 5.0 in 1998", taking into account "all the feedback we get between now 
and Thanksgiving 1998." Third, Miller also wanted to write "a proposal (to ACM, IEEE, 
NSF,...) for us three to get together again in Dec 1998." Last after that December 
meeting, they would "start [suggesting] the changes to the powers that be." Apparently, 
after a week of vacation. Miller was willing to go on a little longer "trying to please 
everyone over and over." 

Rogerson respjnded two days later (December 29)— with a copy to Miller. 
Though giving no indication that he had seen Miller's message, he too suggested that 
Gotterbam "send an email explaining that we are now in Version 4 and that their 
comments will be fed into the ongoing maintenance and development of the code and its 
associated accessories (teaching packs and so on)." Apparently, Rogerson did not 
anticipate Version 5, but he was sure that the executive committee "must teep all this 
feedback and eventually write up the f indings^outcomes in a p^:er for CACM or ???"' ' 

10.8 What next? 

That was a good ending to 1997. Would 1998 be a h^Dpy new year? The 
executive committee could not know. They did not even know v\tether SEEPP still 
existed or had, upon delivery of Version 4, automatically dissolved into so many 
individuals again Indeed, they did not even know v\tether the Steering Committee still 
existed It had, after alt only five months ago threatened to go out of existence at the end 
of 1997. It gave no indication of life. The transmittal of Version 4 had not been 
acknov\dedged There had not even been a "thank you" from Cahrara or Frailey. If the 
Steering Committee no longer existed, v\to would guide the code through ACM and 
lEEE-CS ^Dproval? New problems to replace the old 
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10. Appendix: 

SOFTWARE ENGINEERIMG CODE OF ETHICS AND 

PROFESSEONAL PRACJTCE 

(version 4) as recommended by the 

lEEE-CS/ACM Joint Task Force on Software Engineering Ethics and Professional 

Practices 

Short VaTsion 

PREAMBLE 

The short version of the code gives the aspirational elements at a high level of 
abstraction; the clauses that are included in the full version give examples and details of 
how these aspirations change the way we act as software engineering professionals. 
Without the aspirations, the details can become legalistic and tedious; without the details, 
the aspirations can become high sounding but empty; together, the aspirations and the 
details form a cohesive code. 

Software engineers shall commit themselves to making the analysis, specification, 
design, development, testing and maintenance of software a beneficial and respected 
profession. In accordance with their commitment to the health, safety and welfare of the 
public, software engineers shall adhere to the following H^ Piiiidpj.es 

1 PUBLIC - Software engineers shall always act consistent with the public interest. 

2 CLIENT OR EMPLOYER - Software engineers shall act in the best interests of their 
client or employer consistent with the public interest. 

3 PRODUCT - Software engineers shall ensure that their products and related 
modifications are of the highest professional standards possible. 

4JUDGEMENT - Software engineers shall maintain integrity and independence in their 
professional judgement. 

5 MANAGEMENT - Software engineering managers and leaders shall subscribe to and 
promote an ethical approach to the administration of software development. 

6 PROFESSION - Software engineers shall advance the integrity and reputation of the 
profession consistent with the public interest. 

7 COLLEAGUES - Software engineers shall be fair to and supportive of their 
colleagues. 

8 SELF - Software engineers shall participate in lifelong learning regarding the practice 
of their profession. 
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SOFTWARE ENGINEERIMG CODE OF ETHICS AND 

PROFESSIONAL PRACTICE 

lEEE-CS/ACM Joint Task Force on Software Engineering Ethics and Professional 
Practices 

Full VoTsion 

PREAMBLE 

Computers have a central and growing role in commerce, industry, government, 
medicine, education, entertainment and society at large. Those who contribute, by direct 
participation or by teaching, to the analysis, specification, design, development, 
maintenance and testing of software systems have significant opportunities to do good or 
cause harm, to enable others to do good or cause harm, or to influence others to do good 
or cause harm. To ensure, as much as possible, that this power will be used for good, 
software engineers must commit themselves to making software engineering a beneficial 
and respected profession. In accordance with that commitment, software engineers shall 
adhere to the following Code of Ethics and Professional Practice. 

The Code contains eight Principles related to the behavior of and decisions made by 
professional software engineers, including practitioners, educators, managers, supervisors 
and policy makers, as well as trainees and students of the profession. The Principles 
identify the ethically responsible relationships in which individuals, groups, and 
organizations participate and the primary obligations within these relationships. The 
Clauses of each Principle are illustrations of some of the obligations included in these 
relationships. These obligations are founded in the software engineers' humanity, special 
care owed to people affected by their work, and the unique elements of the practice of 
software engineering. The Code prescribes these as obligations of anyone claiming to be 
or aspiring to be a software engineer. 

It is not intended that the individual parts of the Code be used in isolation to justify errors 
of omission or commission. The list of Principles and Clauses is not exhaustive, and 
should not be read as separating the acceptable from the unacceptable in professional 
conduct in all practical situations. The Code is not a simple ethical algorithm which 
generates ethical decisions. In some situations standards may be in tension with each 
other or with standards from other sources. These situations require the software 
engineer to use ethical judgement to act in a manner which is most consistent with the 
spirit of the Code of Ethics and Professional Practice, given the circumstances. 

Ethical tensions can best be addressed by thoughtful consideration of fundamental 
principles, rather than blind reliance on detailed regulations. These Principles should 
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influence software engineers to consider broadly who is affected by their work; to 
examine if they and their colleagues are treating other human beings with due respect; to 
speculate on how the public, if reasonably well informed, would view their decisions; to 
analyze how the least empowered will be affected by their decisions; and to consider 
whether their acts would be judged worthy of the ideal professional working as a 
software engineer. In all these judgements concern for the health, safety and welfare of 
the public is primary. That is, the "Public Interest" is central to this Code. 

The dynamic and demanding context of software engineering requires a code that is 
adaptable and relevant to new situations as they occur. However, even in this generality, 
the Code provides support for software engineers and managers of software engineers 
who need to take positive action in a specific case by documenting the ethical stance of 
the profession. The Code provides an ethical foundation to which individuals within 
teams and the team as a whole can appeal. The Code helps to define those actions which 
are ethically improper to request of a software engineer or teams of software engineers. 

The Code is not simply for adjudicating the nature of questionable acts; it also has an 
important educational function. Since it expresses the consensus of the profession on 
ethical issues, it is a means to educate both the public and aspiring professionals about the 
ethical obligations of all software engineers. 



PRINCIPLES 

PdudpAe 1 PUBLIC Software engineers shall always act consistent with the public 
interest. In particular, software engineers shall, as appropriate: 

1 .01 . Accept full responsibility for their own work. 

1.02. Moderate the interests of the software engineer, the employer, the client and the 
users with the public good. 

1.03. Approve software only if they have a well-founded belief that it is safe, meets 
specifications, has passed appropriate tests, and does not diminish quality of life 
or harm the environment. 

1 .04. Disclose to appropriate persons or authorities any actual or potential danger to the 
user, the public, or the environment, that they reasonably believe to be associated 
with software or related documents. 

1.05. Co-operate in efforts to address matters of grave public concern caused by 
software or related documents. 

1.06. Be fair and avoid deception in all statements, particularly public ones, concerning 
software or related documents. 

1.07. Consider issues of physical disabilities, allocation of resources, economic 
disadvantage and other factors that can diminish access to the benefits of 
software. 

1.08. Volunteer professional skills to good causes and contribute to public education 
concerning the discipline. 
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Pdiici[d.e 2 CLIENT OR EMPLOYER Software engineers shall act in the best interests 
of their client or employer consistent with the public interest. In particular, software 
engineers shall, as appropriate: 

2.01. Provide service in their areas of competence, being honest and forthright about 
any limitations of their experience and education. 

2.02. Not knowingly use software that is obtained or retained either illegally or 
unethically. 

2.03. Use the property of a client or employer only in ways properly authorized, and 
with the client's or employer's knowledge and consent. 

2.04. Ensure that any document upon which they rely has been approved, when 
required, by someone authorized to approve it. 

2.05. Keep private any confidential information gained in their professional work, 
where such confidentiality is consistent with the public interest. 

2.06. Identify, document, and report to the client or the employer promptly if, in their 
opinion, a project is likely to fail, to prove too expensive, to violate intellectual 
property legislation, or otherwise to be problematic. 

2.07. Identify, document, and report significant issues of social concern, of which they 
are aware, in software or related documents to the employer or the client. 

2.08. Accept no outside work detrimental to the work they perform for their primary 
employer. 

2.09. Promote no interest adverse to their employer or client, unless a higher ethical 
concern is being compromised; in that case, inform the employer or another 
appropriate authority of the ethical concern. 



PdudpAe 3 PRODUCT Software engineers shall ensure that their products and related 
modifications are of the highest professional standards possible. In particular, software 
engineers shall, as appropriate: 



3.01. Strive for high quality, acceptable cost and a reasonable schedule, ensuring 
significant tradeoffs are clear to and accepted by the employer, the client, the user 
and the public. 

3.02. Ensure proper and achievable goals and objectives for any project on which they 
work or propose. 

3.03. Work to identify, define and address ethical, economic, cultural, legal, and 
environmental issues related to work projects. 

3.04. Ensure that they are qualified, by an appropriate combination of education, 
planned education, and experience, for any project on which they work or propose 
to work. 

3.05. Ensure an appropriate methodology for any project on which they work or 
propose to work. 

3.06. Work to follow industry standards when available that are most appropriate for 
the task at hand, departing from these only when technically justified. 



298 



3.07. Strive to fully understand the specifications for software on which they work. 

3.08. Ensure that specifications for software on which they work have been well 
documented, satisfy the users' requirements, and have the appropriate approvals. 

3.09. Ensure realistic estimates of cost scheduling, personnel, and outcomes on any 
project on which they work or propose to work and provide a risk assessment of 
these estimates. 

3.10. Ensure adequate testing, debugging, and review of software and related 
documents on which they work. 

3.11. Ensure adequate documentation, including significant problems discovered and 
solutions adopted, for any project on which they work. 

3.12. Work to develop software and related documents that respect the privacy of those 
who will be affected by that software. 

3.13. Be careful to use only accurate data derived by ethical and lawful means, and use 
only in ways properly authorized. 

3.14. Maintain the integrity of data, being sensitive to outdated or flawed occurrences 
3.15 Treat software maintenance with the same professionalism as new development. 



PdudpAe 4 JLDGEMENT Software engineers shall maintain integrity and 
independence in their professional judgement. In particular, software engineers shall, as 
appropriate: 

4.01. Temper all technical judgements by the need to support and maintain human 

values. 
4.02 Only endorse documents prepared under their supervision or within their areas of 

competence and with which they are in agreement. 

4.03. Maintain professional objectivity with respect to any software or related 
documents they are asked to evaluate. 

4.04. Not engage in deceptive financial practices such as bribery, double billing, or 
other improper financial practices. 

4.05. Disclose to all concerned parties those conflicts of interest that cannot reasonably 
be avoided or escaped. 

4.06. Refuse to participate, as members or advisors, in a governmental or professional 
body concerned with software related issues, in which they, their employers, or 
their clients have undisclosed potential conflicts of interest. 



Pdudide 5 MANAGEMENT Software engineering managers and leaders shall 
subscribe to and promote an ethical approach to the administration of software 
development. In particular, those managing or leading software engineers shall, as 
appropriate: 

5.01 Ensure good management for any project on which they work, including effective 

procedures for promotion of quality and reduction of risk. 
5.02. Ensure that software engineers are informed of standards before being held to 

them. 
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5.03. Ensure that software engineers know the employer's policies and procedures for 
protecting passwords, files, and other confidential information. 

5.04. Assign work only after taking into account appropriate contributions of education 
and experience tempered with a desire to further that education and experience. 

5.05. Ensure realistic estimates of cost scheduling, personnel, and outcome on any 
project on which they work or propose to work, and provide a risk assessment of 
these estimates. 

5.06. Attract potential software engineers only by full and accurate description of the 
conditions of employment. 

5.07. Offer fair and just remuneration. 

5.08. Not unjustly prevent someone from taking a better position for which that person 
is suitably qualified. 

5.09. Ensure that there is a fair agreement concerning ownership of any software, 
processes, research, writing, or other intellectual property to which a software 
engineer has contributed. 

5.10. Provide for due process in hearing charges of violation of an employer's policy or 
of this Code. 

5.11. Not ask a software engineer to do anything inconsistent with this Code. 

5.12. Not punish anyone for expressing ethical concerns about a project. 



Prindple 6 PROFESSION Software engineers shall advance the integrity and reputation 
of the profession consistent with the public interest. In particular, software engineers 
shall, as appropriate: 

6.01 . Help develop an organizational environment favorable to acting ethically. 

6.02. Promote public knowledge of software engineering. 

6.03. Extend software engineering knowledge by appropriate participation in 
professional organizations, meetings and publications. 

6.04. Support, as members of a profession, other software engineers striving to follow 
this Code. 

6.05. Not promote their own interest at the expense of the profession. 

6.06. Obey all laws governing their work, unless, in exceptional circumstances, such 
compliance is inconsistent with the public interest. 

6.07. Be accurate in stating the characteristics of software on which they work, 
avoiding not only false claims but also claims that might reasonably be supposed 
to be deceptive, misleading, or doubtful. 

6.08. Take responsibility for detecting, correcting, and reporting errors in software and 
associated documents on which they work. 

6.09. Ensure that clients, employers, and supervisors know of the software engineer's 
commitment to this Code of ethics, and the subsequent ramifications of such 
commitment. 

6.10. Avoid associations with disreputable businesses and organizations. 

6.11. Consider that violations of this Code are inconsistent with being a professional 
software engineer. 
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6.12. Express concerns to the people involved when significant violations of this Code 
are detected unless this is impossible, ineffective, or dangerous. 

6.13. Report significant violations of this Code to appropriate authorities when it is 
clear that consultation about the problems is impossible, ineffective or dangerous. 



PdudpAe 7 COLLEAGUES Software engineers shall be fair to and supportive of their 
colleagues. In particular, software engineers shall, as appropriate: 

7.01 . Encourage colleagues to adhere to this Code 

7.02. Assist colleagues in professional development. 

7.03. Credit fully the work of others and refrain from taking undue credit. 

7.04. Review the work of others in an objective, candid, and properly- documented way. 

7.05. Give a fair hearing to the opinion, concern, or complaint of a colleague. 

7.06. Assist colleagues in being fully aware of current standard work practices 
including policies and procedures for protecting passwords, files and other 
confidential information, and security measures in general. 

7.07. Not unfairly intervene in the career of any colleague; however, concern for the 
employer, the client or public interest may compel software engineers, in good 
faith, to question the competence of a colleague. 

7.08. In situations outside of their own areas of competence, call upon the opinions of 
other professionals who have competence in that area. 



PdudpAe 8 SELF Software engineers shall participate in lifelong learning regarding the 
practice of their profession. In particular, software engineers shall continually endeavor 
to: 

8.01. Further their knowledge of developments in the analysis, specification, design, 
development, maintenance and testing of software and related documents, 
together with the management of the development process. 

8.02. Improve their ability to create safe, reliable, and useful quality software at 
reasonable cost and within a reasonable time. 

8.03. Improve their ability to produce accurate, informative, and literate documentation. 

8.04. Improve their understanding of the software and related documents on which they 
work and of the environment in which they will be used. 

8.05. Improve their knowledge of the law governing the software and related 
documents on which they work. 

8.06. Improve their knowledge of this Code, its interpretation, and its application to 
their work. 

8.07. Not influence others to undertake any action which involves a breach of this 
Code. 

8.08. Consider that personal violations of this Code are inconsistent with being a 
professional software engineer. 
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This Code was developed by the lEEE-CS/ACM joint task force on Software 

Engineering Ethics and Professional Practices: 

Chair: Donald Gotterbam; 

Executive Committee: Keith Miller and Simon Rogerson; 

Members: Steve Barber, Peter Barnes, Ilene Bumstein, Michael Davis, Amr El-Kadi, N. 

Ben Fairweather, Milton Fulghum, N. Jayaram, Tom Jewett, Mark Kanko, Ernie 

Kallman, Duncan Langford, Joyce Currie Little, Ed Mechler, Manuel J. Norman, 

Douglas Phillips, Peter Ron Prinzivalli, Patrick Sullivan, John Weckert, Vivian Weil, S. 

Weisband and Laurie Honour Werth. 
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NOTES 

^ GottedemWension 3\Conimenl\Unger-4 (addressed to Gottedem only). The "4" 

after "Ungei^' indicates that this was the fourth "ballot' in Gotbeibam' s tally (and peih^DS 
the fourth to anive). One of the first three seems to have been Notkin's (no number); 
LaRue' s (below) seems to have come third Whose was the other? Is one lost? Qr was it 
just a ballot without any comment? Neither the archive nor Gotte±)am can tell. 

^ Unger, v\to holds a BS (Brooklyn Polytechnic, 1952), MS (MET, 1953) and ScD 

(MTT, 1957), all in electrical engineering, had worted at Bdl Labs (1957-61) before 
becoming a professor. As part of a re-organization there, he was asted to head a group to 
develop a conpler for the first electronic telephone switching system (ESS). He agreed 
to do that for a limited time. He was in charge of the conpler group for two years. Later 
he did theoretical work on software (e.g., a prc)gram for a syntax analyzer). He is now a 
professor in the Conpjter Science Department of Coliintaa University and also a 
professor in the Electrical Engineering Department Unger dislites the terai "conpjter 
science": "Science is about understanding nature. Engineering is about making artifacts. 
Software is an artifact Ctonpitersdence is about rnakingconpjters and software. That s 
engineering, as far I am concerned" Interview of Unger, November 13, 2002. Though 
never involved in SEEPP, he had been in contact with Gottertem for some time. His 
nanK first ^Dpears in Gotteri:am\SEEP 1994r96\PCVOL3 (file date 6-8-95) in an 
unsigned note (^Dparently sent to Gotteatam by some third person): 

Steve Unger is on the new IEEE International Ethics Committee and with others 
we are hdpng Steve inclement a mechanism to help IEEE members (later we 
hope to extend to others working in EE/CS) in ethics matters. The support of your 
ta^ force is desired (We of course need to tell you about it By CC to Steve I'm 
asking him to do so. 

Apart from that I would lite to be involved in SEEPP in some way. Thanks. 

The official title of the committee in question is 'IEEE Ethics Committee". The parent 
organization of IEEE-USA is just IEEE (though most men±)ers I know tend to refer to 
IEEE-USA as 'IEEE" and the worid-wide parent as "IEEE International"— v\ten they 
bother to distinguish the two). 

^ Stephen Unger, Controlling Technology (John Wiley and Sons: New York, 1994). 

Among his important articles then were: "Role of Engineering Societies in Controlling 
Hazardous Technology", Journfll of Professional Issues in Engineering 112 (July 1986): 
151-157; "Would Helping Ethical Professionals Get Professional Societies in Trouble?" 
Conference Record - Electro, 1987 (5. 4. 1-5. 4. 6); and "BART Case: Ethics and the 
Employed Engineer", Communications Society 12 (May 1974): 11-13. He had, of course, 
also published a great many technical papers. 

* The reason for the substitution of the 1990 code for the 1987 one is not clear, but 

it seems to be a product of conqiex relations between IEEE-USA and its parent 
organization ('IEEE"). 
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^ These wisre the Ethical Guidelines WalterElden'sgroupvvasvvoikingon (9.1). 

^ Tte phrase 'Tair and tmthfid"vvas my rendering of the sta^^ 

engineering codes, "otgective and tnjthful". I had substituted "faii^' for "otgective" 
because of post-modern concerns about the possLbUity of otgectivity. Unger" s suggestion 
way be an instance of a tendency all writers notice. Change one word in a well-known 
phrase and it becomes much easier to change others. Perii^:s if I had not substituted 
"faii^' for "otgective", Unger would not have suggested tte double negative, "avoid 
deception". On a better day, he might have suggested something more positive, such as 
"carriid" for "tmthful". Aryone v\to writes a code will, I think, soon be surprised at 
v\tot gets read in or read out Gotteibam still thinks that my "fair and tmthful" does not 
"not cleariy dimtnate the possitality of deception by omission". Gottertem 
Ch^Dter9.cmtd (Septen±)er 29, 2004). I thought "fair" eliminated deception by omissiorL 

^ GotberbamWersion 3\Survey Comment^LARUE-3. 

*" The six Uncertains were: 1.10 ("respect privacy"), 1.11 ("derive data from legal 

sourses", 1.13 ("identify ethical, economic... issues"), 2.01 ("disclose dangers"), 6.07 
("remuneration appropriate to qualifications"), and 8.08 ("violations of the code"). 

^ The two Opposed were: 2.07 ("not put self-interest") and 3.07 ("refuse to 

participate"). 

' ° In Version 1, 2.01 had read: 'Disclose to ^Dpropriate persons any danger that the 
softwareorrdateddocurnentsonv\Mchthey work rnay pose to the user, athird party, or 
the environment" 

'' In Version 1, this clause was 2.06: "Not put self-interest the interest of an 
employer, or the interest of a client or customer ahead of the public's interest" Version 3 
had dropped "customer" (presumably because it is redundant) and added "the interests of 
the user'' (presumably because the user's interest is not identical with the public interest). 
I regard this change as an improvement— and clearly not the cause of the opposition of 
our Omaha respondent 

'^ Perhaps the CtoBlH respondent was proposing a r^urn to the ^proach taken in 
the IEEE's first code of ethics (the 1914 code of ethics of v\tot was ttoi the American 
Institute of Electrical Engineering). Paragr^ii A.2 read 

It is the duty of the engineer to satisfy himself to the best of his atality that the 
enterprises with v\Mch he becomes identified are of legitimate character. If after 
becoming associated with an enterprise he finds it to be of questionable character, 
he should sever his connection with it as soon as practicable. 

Engineers seem eventually to have decided that such a pre-qualification clause did not 
provide enough protection for the public. 
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^^ The respondent from Omaha otgects to 3.07 that "'refuse' is too strong" and to 
6.07 that he does not see how "appropriate remuneration [is to be] deteraiined". 

^^ GotteriDamWension 3\Suivey Comment^CARTMEL. The author of this email 
was then the principal in Caitmdl Technologies of Kingston, New Yoric, a consulting 
f imi advising on assistive technologies. http://www.ulster.net^~dcartm. 

^^ Clause 1.07 (Vension 3.1) read: "Ensure realistic estimates of cost, scheduling, 
personnel, and outcome on any project on v\Mch they woric or propose to woric and 
provide a risk assessment of fh^ estimates." 

'^ GotteriDamWeision 3\Survey Comments\TAYLOR This respjndent has a BS 
(1989), an MS (1991), and a PhD. (1994), all in Con^iuter Science and all from 
University of Noith Carolina-Ch^:el HU. His dissertation was titled "The 
Nanomardpulaton A Virtual-Reality Interface to a Scanning Tunneling Microscope". 
Since 1994, as an NSF CISE Postdoctoral Research Associate (and with additional 
obtained funding), he has directed the nanoManipulator project Research interests 
include virtual environments, man-machine interaction, scientific visualization and 
distributed systems. http//www.cs.unc.edu/ -^aylon/taylorr_CV.html. 

^ ' Email (Gotterbam to Davis), Febmary 22, 2004. 

'^ November 13, 1997. 

'^ 'TNTov 3 The steering committee has asted me to get comments from industry". 
Gotteri3am\Histoiy of SE Code\Histoiy expanded 

^" E971118andE971120. 

^' GottjerbamWersion 3\Survey Comments\LANE40. The number "40" seems here 
to indicate the place of Lane's response in some final reckoning, not its place in the 
temporal order of responses. So, for example, LINDLEY29 arrived two weeks after 
LANE40. 

^^ The TI respondent must have been thinking of large systems designed for 
sophisticated clients, not shrink-wrapped software sold to ordinary consumers. 

^^ Clause 1.12 (Version 3.1) read: "Whenever ^Dpropriate, delete outdated or flawed 
data". Clause 2.02 read "Approve software only if they have a well-founded belief that it 
is safe, meets specifications, has passed appropriate tests, and does not diminish quality 
of life or hami the erMronment" 

^* By December 1, 1997, there were at least 65 ballots. A few others seem to have 
come in too late to be counted I say "At least 65" because that is the highest number of 
votes on ariy line of the table saved in Gotteri3am\Version 3\V3 (a file saved on 12-3-97). 
Is 65 a good response or a bad? In proportion to the hundreds of thousands of software 
engineers who could have respjnded, 65 seems almost no respjnse at all. But, given the 
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quality of the responses, and the small number of respondents in any step of the process 
so far, 65 looks pretty good. 

^^ Email (Gotbedam to Davis), Febmary 22, 2004 (departmental support;). 
GotleriDamWeision 3\Suivey QjrnrnentsVALLCMNTS. This is identical with: Survey 
Conin£nts\CMrS20NOV. 

^^ This is a good idea for dealing with a persistent conplaint resting on an 
undefended pigudice. But it is not as radical or as ACMish as GotberiDam mates it sound 
On the one hand, even Version I's Rules were designed so that (minus the 'In 
particular. . .") they could stand alone to form a short code. After all, I had before one 
m^or engineering codes (ABET's) that had a short and a long version related in 
something lite this way. The executive commitiee did not need to change the wording of 
any Principle. On the other hand, the ACM, having originally printed its document with 
the code of ethics first and the guidelines after (with each set of the guidelines preceded 
ty the ^Dpropriate provision of the code) was ty 1997 printing just the guidelines. ACM 
seems to have treated the short version as a mere inconvenience necessary for approval. 
By 1997, v\tot GotieriDam was proposing was not (or, at least, no longer) the "ACM 
nixM". 

" irr Archive 1997, New Folder (Noven±)er 21, 1997). 

^^ irr Archive 1997, New Folder (Noven±)er 21, 1997). 

^^ Gotberbam\SEEP1994r65\OPGUIDE. 

^° 4.3.5.C ('This category is provided to allow for ballot returns from men±)ers v\to 
do not wish to review documents because of conflict of interest, lack of expertise, or 
other reasons. A reason shall be given for this vote; otherwise, the ballot shall be 
classified as 'no response.' ") 
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GotieriDamWersion 3\Survey comment^STPAUL. 



^^ Gotterbam, email (March 2, 2004) added that smaller companies seldom have 
such adoption problems. His Google search using "Software Engineering Code of Ethics" 
even revealed small companies that use adoption of the code in tiieir advertising. 

^^ GotterbamWersion 3\ALLCMNTS (file date 12/3/1997). This seems to be the 
same as: GotterbamWersion 3\Survey Comments\ALLCMNTS (file date 12/1/1997). 
The earlier document is actually one third longer, but there are several anomalies (such as 
four pages in which words are printed one letter per line) that make comparing length 
harder. 

^* When there was no vote at all on a particular clause, the blank was ignored in all 
calculations. 
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^^ Gotteibam\Veision3\VER3nx)(i 

^® The twenty clauses 3b set in bold for inspection were: 1 .04, 1 .05, 1 .06, 1 .08, 1.12, 
1.15, 2.02, 2.05, 2.07, 2.08, 3.05, 4.02, 4.06, 4.09, 6.03, 6.05, 6.07, 6.13, 7.02, and 7.08. 

^ ^ So, for exanple, the list of names at the end of the code ( "meniDeis") now include 
Weil and me, although there is no indication that it has been changed 

^^ Gotieibam, email (March 3, 2004). 

^^ These comments are now lost Gotlerbam recalls that "some commented briefly 
on several of the clauses, ...descritang v\^ they had voted negative or positive, 
advocating that a clause be made even stronger, etc." But, from the summary of 
comments, it seems to me that the faxed ballots could not have contained much beyond 
the vote itself— or there would be comments quoted in the summary that do not 
correspond to emails saved in Gotlerbam' s archive. I have been unable to identify ariy. 
Gotlerbam, email (March 4, 2004) and (March 8, 2004 attachment). 
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Email (MUerto Davis), March 15, 2004. 

Gotterbam, email (March 4, 2004). Miller, email (March 15, 2004). 

Gotlerbam, email (March 4, 2004). 

Gotlerbam, email (March 3, 2004). Corrpare Miller (email, March 15, 2004): 

Marry academics love to debate (niyself included), but often that can lead to 
acrimory. In this case, I found it exhilarating to be in an intense, intellectual 
exchange vMle knowing that each of us was working towards the same goal— a 
better code. I think we tmsted and respected each other enough to say exactly 
what we thought, and I never fdt attacted or even annoyed We could g^ 
exasperated sometimes, but I remember us being in good hurnorrnost of the time. 
(Don and Simon "ganged up" on me once because I didn't lite a word or spelling, 
and they assured me it was good English, from the United Kingdom, and that I 
was being a contrary Yank, or something lite that) 

Gotterbam on this point (Email March 3, 2004): 



While 7.08, with one of the weatest endorsements (85%), was marted for 
revision or deletion, 2.03 was not With almost 97% in favor of it it should have been 
immune to change, much less ddetion At the least such deletions should have been 
noted GotterbamWension 3\V3 Survey Votes. 

" Version 4 was 2706 words conq^ared to Version 3' s 3407 (and Version I's 1517). 
It is interesting to note that Version 4 is about the same length as Version 2. 1 (2759) . It is 
3.0 (3407 words) that is the outiier among the executive committee' s codes— and, indeed, 
among m^or codes from engineering and conpjter science. The conplete ACM code is 
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2837 words; the NSPE's, 2218; and the ABET Guidelines, 2666. Did Gotterbam realize 
that Version 3 was unusually long? He certainly knew that Version 4 was much shorter. 
See GotterbamWersion 4\M0DS ("A brief summary of the general direction of the 
modifications on version 3 to make A"), a rough draft never completed (file date 
12/16/1997): "The Code was reduced in size by 30%...."— There seem to be at least three 
ways to calculate the reduction from 3.0 to 4.0 so that it is 30% (as opposed to the 25% I 
calculated): 1) treat Version 4 rather than Version 3 as the base (though that would yield 
a 33% reduction); 2) treat only the first digit of the percentage as a significant number 
(and rounding up to 30% from 25.6%); or 3) combining 1 and 2 (rounding down from 
33%). 
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Gotterbam\Vei:sion4\S12), December 12, 1997. 



*^ WhyhadIresp)ndedtotliscdlfor(X)niiiientvvhenIh^ 
Gotle±iam had issued? In part, I responded because I could easily do so. The request had 
anived v\ten classes were over, all p^:eis graded, and the final exam ready but not yet 
given I had a relatively clean desk. (Had the request come a week earlier, I would not 
have been able to respond in time, since I was then out of the counhy— and offline.) But, 
in part too, I responded because I thought it was time to give some advice on drafting. I 
was hinting that the executive committee would do well to choose me as the editor I had 
suggested Their choosing me for the job did not seem as much of a stretch as it would 
have six months eariier. By then, Gottedem knew much of the story of Version 1 
because I had asted him to comment on a first draft of a little p^:er eventually putiished 
as: Michael Davis, "Writing a Code of Ethics by E-Mail: Adventures wilii Software 
Engineers", Science Communication 21 (June 2000): 392-405. (I thanked Gotterbam for 
his comments in a postscript to the December 9 fax.) 

^^ I also suggested that 4.04 should not begin "Do not engage" because the "shall" in 
the introductory "In particular" phrase above controls: "one modal is enough." (The final 
Version 4 corrected this error.) From niy perspective, and pedi^:s from the executive 
committee' s, we were involved with "debugging" a pretty "buggy" code. 

^ ° I also took exception to the language of this Principle: "' within confines of . Dead 
met^hor. Presumably, it means the same as the shorter (and more common) 'consistent 
with' ." The final Version 4 was revised accordingly. 

^' Gotterbam probably did rot treat niy cornrnents in this vvay because a three-page 
fax was not easily forwarded to the list. He would either have had to retype fax or scan it 
(and, in 1997, scanners were still not neariy as common, reliable, or easy to use as they 
would be even two years later). Gottedem must, however, have passed my comments on 
to Rogerson and Miller (in some form or other). Miller and Rogerson (in their responses 
to Fairweather' s comments below) each refer to my comments once (though both call me 
"M Davies", indicating a single, but mangled, source). The references are to different 
parts of n^^ comments. 
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^^ I had a different otgection to Principle 3, specifically to its "products and related 
modifications": "Modifications are generally modifications of something. If of products, 
they are products. If of something else, v\tot? Frankly, 'modifications' just strifes me as 
confusing." Even Version 5.2 retained this unfortunate expression. 

^^ In the next version of the code (December 18, 1997), the short version had two 
paragi^iis instead of one, the paragi^ii coming first doing as Fairweather had 
suggested. Rogerson's okay was not always so potent, however. For exanqie, having 
noted the change from "enployee" to "software engineer" in 5.02 and other clauses under 
Principle 5, Fairweather pointed out that a software engineer "may be leading a team that 
includes people other thcoi software engineers (for exanqie, administrative support)." The 
good softwa:e engineer-manager "should not punish -terry-l- enqioyee for expressing 
ethical concerns about a project, or ask smy enployee to do ariything inconsistent with 
this Code, [and so on]." Rogerson seemed to concede the point, "Interesting— suggest we 
change 'a software engineer^ to 'smyone' ." Miller did not otgect Yet, the next version— 
and all its successors— preserved "software engineer". Apparently, sometimes 
Gotterbam' s vote was all that mattered 

^^ "Without the asprations, the details can become legalistic and tedious; without the 
details, the asprations can become high sounding but en^Dly; together, the asprations and 
the details form a cohesive code." Philosophers may wonder at the similarity between 
Miller's language and a famous ^±Drism in Kanf s Critique of Pure Reason: "Thoughts 
without contents are empty, intuitions without concepts are blind." 

^^ "Gottej±iam\History of SE code\History expanded" reports that the web posting 
occuned two days laten "Dec 18 version 4 place on SEERl web site announcing that it 
was recommended to the two societies." 

" The expression "being sent" is, peih^:s, a lit misleading. The suggestion is that 
the document is even now on its way to the Steering Committee. In fact, from dating on 
the files of supporting documents, it seems liMy that Gottertem did not actually email 
the "final version" to the Steering Committee until the next day, December 16 (after his 
grades had been turned in). December 16 is also the date given in Gotteibam's own 
chronology: Gottej±)am\History of SE code\history expanded ("Version 4 to both 
societies for ^proval- December 16 1997"). A related technicality: By Gotterbam' s 
usual measure, the version sent the Steering Committee (what the email to the task force 
called "Version 4.D0NE") should have been "Version 4.1", since its immediate 
predecessor was Version 4.0 (Decen±)er 7, 1997) and that Version 4 differed from this 
Version 4 in marry ways small and large. In fact, "Version 4. DONE" (December 15, 
1997) would thereafter be Version 4. This is confusing. So, wherever there is a risk of 
confusion, I will date the version of 4 in question or otherwise make clear which I intend. 
(Gotterbam explained his notation this way: "Even though there is a big difference 
between the 4 of December 7 and the 4 of December 15, we did not bother to assign 
different version numbers to the paper copies because we did not consider the submission 
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to the task force to be a release, only a step in drafting." Email, Gotterbam to Davis, 
March 8, 2004.) 

^^ Because Rogenson was writing from England, the timestanp for this message is 
2:30 PM (that is, 9:30 AM CST). 

^^ Late that afternoon (December 16, 1997), Ron Prinzivalli wrote the listserv, 
"What is this?" Was he asking about Version 4.D0NE or the parties in Rotterdam and 
Washington? We cannot tell. No one seems to have lespjnded to his cry for 
clarification— and he was already dead when I called for an interview (September 2003) . 

^° December 17, 1997. 

^^ Gotteri3am\Steering Committee\Recommendation of 4\REC (December 16, 
1997). The letter begins (after the date) with the salutation: 'To the Joint lEEE-CS/ACM 
Steering Committee on the Professionalization of Software Engineering and Executive 
Committees of the ACM and the lEEE-CS." Because the file is not itself an email, we 
cannot tell to v\tom this message was sent or v\terL But it seems reasonable to suppose 
that Gottertam would have sent it to Cabrera, with a copy to Frailey, as he regulariy did 
v\ten dealing with the Steering Committee, and that he would have sent the letter to the 
other Committee members through the presiding officer (rather than directly). The only 
confusion seems to concern to v\tom the recommendation was sent "Gottertem\History 
of SE code\Histoiy expanded" mentions only the two societies (omitting the Steering 
Committee). This seems a slip. The Steering Committee's chair and co-chair never 
denied receiving the December 16, 1997, letter of transmittal. The inpoitance of these 
details will become obvious in the next chapter 

^ ^ For more detail, including the exact working group involved and v\tot it reported, 
see 8.7 (and endnote). 
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The archives contain no record of this correspondence. 
These requests are not in the archive. 

GotterbamWersion 3\Feedback on 3\Wentworth (December 22, 1997). 

GotterbamWersion 3\Survey comments\Siemenscommnt. 

The language of these clauses does not matter here. For the exact wording of 
these clauses, see 9. Appendix. 

^^ Version 3.0' s 6.10 ("Obey all laws governing their work, insofar as such 
obedience is consistent with the public health, safety, and welfare ") had become Version 
4's 6.04 ("Obey all laws governing their worlc, unless, in exceptional drcumstances, such 
conpliance is inconsistent with the public interest"). Would this 6.04 have satisfied the 
Geraian? What of the ancestor of all these. Version I's 5.10 ("Obey all laws governing 
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their work, insofar as such obedience is consistent with the public health, safety, and 
welfare")? 

^^ The original of this email has not survived, but we have it conplete both in 
Miller's response (GottertemWension 3\ Survey Comment^KM) and Rogenson's 
(GotteatamWeision 3\Survey CommentsVASI). 

^° GotiedemWension 3\ Survey Con]ments\A.KM. 

^^ GotledamWension 3\Survey Comment^SI. 
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Chapter 11: The Long Process of Appro^ 1998 

"Whenever you set out to do something, something else must be done first." 

— Murphy's Law #12 

1 1 . 1 A n unpleasant surprise 

After all the activity of 1997, Gotterbam enjoyed the relative calm of the first few weeks 
of 1998. Only a few Code- related emails, like stragglers after a great battle, drifted in from time 
to time. The first arrived on January 7. Its author, a sixth-year student in computer science at the 
Technical University of Eindhoven, had a page and a half of "opinions and criticisms" 
concerning Version 3 (9. Appendix). While he liked most of the Code, he thought it "geared 
towards software engineers working in a (large) company." As an "independent software 
engineer", he "personally" disliked "this point of view". Since most codes of engineering ethics 
have been criticized for not paying enough attention to engineers working in large organizations 
(large organizations being where most engineers work), the Dutch student had, however 
unintentionally, complimented the Gotterbam. 

The Dutch student also thought the Code felt "very US-oriented". Several "political[ly] 
correct terms" obscured "the meaning for us foreigners". Had Version 4 taken care of that 
problem (10. Appendix)? For example, the old "diversity" clause (renumbered 1.07) now read: 
"Consider issues of physical disabilities, allocation of resources, economic disadvantage and 
other factors that can diminish access to software." No "politically correct terms" there. Perhaps 
Version 4 had taken care of another problem as well.^ The Dutch student was concerned that 
some clauses "way be in violation of local laws". The only exanqie he gave was "5.05" 
('Develop a fair agreement concerning ownensihip of ariy sofbA^, pnxesses, research, writing, 
or other intellectual property to v\Mch an errqioyee has contributed"). Version 4 had dropped 
that clause; perti^:s it had done the same with others the Dutch student might have mentioned^ 
This email from the Nethedands seemed to endorse v\tot the executive committee had done in 
Baltimore. 

Much the same was tme of a much longer (six page) email, equally thoughtful, that 
arrived the next day from Switzedand Its author, George Sigut, held a position at the Federal 
Institute of Technology in Zurich much lite that Manriy Nomian held at Eastern Mchigaa In 
charge of Conpjter Services for the Institute, he was a software engineer practicing within an 
academic (research) erMronment^ Sigut proposed "1 Changes in the form [;] 2 Changes in the 
Principles [; and] 3 Other changes". One of the changes in form, though different from v\tot 
Gotterbam, Miller, and Rogerson had made in December, was surprisingly similar. Sigut 
proposed that, instead of Version 3's two-part division into Preamble and Principles (with 
Clauses), the Code should have a three-part division: Preamble; Principles; and Clauses. He 
wanted the reader to be able "to consider the Principles on their own [without a m^or effort]". 
Version 4's "short version" made that possible. Lite some other critics, Sigut also wanted to 
distinguish clauses according to the three categories described in Version 3' s Preamble ( Aspre, 
Expect, and Demand). Gotteibam, Miller, and Rogerson had considered doing that too, but had 
instead abandoned explicit mention of the categories to avoid confusion Patiaps Sigut would 
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have agreed that deletion of the distinction was an equally good way to resolve the problem he 
had identified. Why not? 

Sigut had given the Preamble considerable attention. His suggestions for changes 
constitute about a quarter of the entire six-page email. Their general drift is to sharpen the 
distinction between Principles and Clauses (a distinction fundamental to the design of the Code 
yet a source of misunderstanding ever since Version 1). For example, his "Point 5" is to amend 
the fifth paragraph by deleting "Principles and" from the sentence, "The list of Principles and 
Clauses is not exhaustive." The reason for this change is (he suggested) obvious: "Principles are 
exhaustive by definition". He was, in part, suggesting a reversion to the language of Version 1 
("no set of subsidiary clauses exhausts the general rule [Principle]"). But he also seemed to be 
making a larger point about the Principles, something Version 1 did not. The Principles defined 
the special responsibilities of software engineers (what moral obligations they have beyond what 
everyone else has). The Principles might, if badly designed, leave something out that should 
have been included. But what was left out would be something that should be a special 
responsibility, not something that is. That is the sense in which the Principles are exhaustive "by 
definition". They were supposed to be exhaustive (whether or not they in fact were). The clauses 
were not like that. They were just instances of the Principles. There could always be more 
instances. They were not supposed to be exhaustive.^ 

Sigut also pcted out for revision marry of the clauses Gotlerbam, Miller, and Rogerson 
had already ddded, for exanqie, old 6.07 ("Only accept remuneration ^Dpropriate to 
professional qualifications or experience"). Here and there, though, Sigut identified a problem 
Gotlerbam, Miller, and Rogerson had not For exanple, Sigut says of old 7.06 (also new 7.06) 
that the wording might be inpDved It then read: "Assist colleagues in being fully aware of 
current standard work practices including policies and procedures for protecting passwords, files 
and other confidential information, and security measures in general." Would it not, Sigut asted, 
read better if rewritten to say: "assist colleagues in being fully aware of current standard work 
practices including policies and procedures for protecting passwords, files, security measures in 
general, and other confidential information"? Apparently, Sigut thought "and security measures 
in general" looted tacted on to a well-ordered list He suggested inserting it in the list (without 
the "and"); there would then be only one (longer) list and only one "and" instead of two.^ 

Gotierbam now had a set respjnse for late comments on Version 3. It began, 'Dear 
Enlightened Person" (until the individual's name was inserted). After thanking the enlightened 
ones for "your thoughtful respjnse", it informed them, "We have already factored in numerous 
responses to version 3 of the code and have produced version 4.0." Version 4 (a copy of v\Mch 
was printed below the letter) "is now up before the lEEE-CS/ACM Steering Committee." 
Non^hdess, "[your] comments will be fed into the ongoing maintenance and development of the 
code and its associated accessories (teaching packs and so on)." The results of "this effort" are to 
be available "eariy this year" at the ACM and IEEE websites (and at the website for Rogerson' s 
center). The names of the three members of SEEPFs executive committee ^Dpear below the 
final "Sincerely". 

Gotierbam replied on the same day he received Sigut s email (January 8). Though he 
might have sent Sigut the standard letter, ^Dparentiy he thought Sigut deserved better. 
Addressing him as 'Dear George", Gottedem inserted two sentences in the middle paragr^ii of 
the standard reply: 'The three level distinction in the preamble drew endless debate about v^ch 
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clause went at which level. We removed the distinction from the Preamble and (in general) put 
the more aspirational elements at the top."^ 

A few days later (January 11), another conespondent proposed a new principie or clause 
(^Dpaiently designed to cut across existing Principles) : 

Perform factually-based work analyses and estimations to define validatahle and 
verifiable systems requirements, then only budget adequate resources for hard 
requirements or seek ^Dprovals for reduced scopes of work based on hard budgets prior to 
specifying, accepting ail assigning the work 

The author of this disastrous sentence had a legitimate problem he was trying to solve. Many 
projects "fail because they have a fatally flawed set of requirements or a contradictory mission 
and budget" They are wasteful because of "some preliminary character flaws of the planners and 
upper managers". The software engineer should tterefore be responsible for evaluating the initial 
specifications, revising or rgecting them as ^Dpropriate, not just accepting them in the way a 
"servant" would Who would disagree? But v^ had the author of this email not noticed that 
Version 3 (lite Version 4) had in fact dealt with the problem? Old 1.04 (lite new 3.02) required 
software engineers to: "Ensure proper and achievable goals and otgectives for ariy project on 
which they work or propose."' Had the author of this email read the Code? Perfi^K not There 
was nothing in the email to show that he had 

This commentator plainly deserved nothing more than the standard letter (with perfi^:s a 
reference to the clause that already did v\tot he suggested). But another plainly deserved a 
response even more personalized that the one Gotterbam sent Sigut That commentator had sent 
an email only a half page long, but its author, Stuart Zweben, an ACM-^Dpointed member of the 
original Steering Committee (and retiring ACM president). GotteriDam agreed that Zweben had 
"identified two of the sore spots in version 3.0." But in "eariy Decen±)er we did a significant 
revision of the [Code]." Zweben had not lited the wording of old 3.07 ("Refuse to participate in 
decisions of a governmental or professional body...") or old 2.07 ('TSTot put self-interest, the 
interest of an enployer. . ."). Gotterbam quoted the wording of the corresponding provisions of 
Version 4 (4.06 and 1.02), suggesting that the new wording had taten care of the problems 
Zweben identified Clause 4.06 allowed participation but only after disclosure of ariy conflict of 
interest 1.02 required only that the software engineer "moderate" the interests of self, enqioyer, 
and so on with the public good Gotteri^am concluded by noting that he had "tried to address 
your other question in my 19 January letter to the Steering Committee". He also informed 
Zweben that 'Version 4.0 is available at www.acmorg/serving." Gotteri^am seems to have sent 
this response to Zweben on January 19.^ 

Zweberis email inplidtly told GotteriDam something that worried him When he sent 
Version 4 to the Steering Committee (that is, to Cabrera and FraHey) on Decen±)er 16, 
Gotterbam was anticipating an adoption process rather lite that by v\Mch the ACM had adopted 
its code of ethics. The Steering Committee would prorrglly ^Dprove sending Version 4 to the two 
societies. The Board of Governors of the lEEE-CS would meet in Febmary, consider Version 4, 
and ^Dprove it (perfi^:s with a few amendments); the ACM' s Executive Committee would do the 
same dtout the same time. Gotteri^am might h^e to go before the lEEE-CS Board or the ACM 
Executive Committee to explain this or that he might have to meet privately with individual 
men±)ers of one or the other body; but it would all be over by March. By the first day of Spring, 
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1998, Version 4, or something very like it would be the official Software Engineering Code of 
Ethics and Professional Practice; Gotterbam could turn his full attention to its dissemination— 
and to teaching, to his Institute, and to his other projects. But that schedule required the Steering 
Committee to vote on the Code soon after receiving it. For the last month, Gotterbam had been 
assuming that, though the Steering Committee had not responded to him, it was at least working 
on his recommendation, the holiday season explaining any delay in taking the official vote. What 
Zweben's comments on Version 3 told him was that the Steering Committee was not working on 
the recommendation of Version 4. Indeed, it told him something worse: Cabrera and Frailey had 
not, during the intervening month, even told the rest of the Steering Committee that Version 4 
existed. Why not? Why had Frailey rushed SEEPP to complete work before the end of the year 
if he was not even going to pass the Code on to the Steering Committee's members in 
December? 

To find out, Gotterbam emailed the entire Steering Committee, not just its chair and vice 
chair, a letter similar in substance (but not organization) to the letter by which Gotterbam had 
originally transmitted Version 4.^ The first paragr^ii armounced that SEEPP had sent the 
Steering Commitbee a recommendation in Decen±)er and had "not heard ariy response" since.' ° 
The second paragr^ii worried about timing: "I believe the Board of Governors of the lEEE-CS 
and the Executive Commitbee of the ACM have meetings scheduled in February and I would be 
willing to represent the SEEPP task force at these meetings." Having the Code ^proved at those 
meetings would be "salubrious [because] there are already several events scheduled for February 
and March v\Mch include the Code."" Gotterbam "fired [this] second letter to the whole 
committee 20 January."'^ 

By January 27, Gotterbam had learned enough to write Miller with ddails "[just] to teep 
you up on the fun".' ^ Both Zweben and (Dennis) Frailey had responded to Gotterbam' s "secord 
letter^'. Zweben was "sony [but] the ACM EC met last week and the next meeting in the US is in 
May." In other words, the Steering Commitbee' s failure to act quickly had put the ACM schedule 
for ^Dproval back at least three months. That news was distressing enough, but Frailey' s was 
worse. Frailey was, Gotterbam told Miller, "our only real contact with the commitbee". Cabrera, 
having become irwolved with a m^or project at Microsoft soon after becoming chair, had 
become increasin^y distant from the Committee's work (much as Gotterbam' s co-chair, 
Mdford, had two years before). Though only vice-chair, Frailey had been trying to hold the 
Steering Committee together. He was not doing well. He "did not know the status of the steering 
committee". The quotation marks are Gotterbam' s around Frailey' s exact words. Gotterbam 
reported replying: "co-chair [sic] did not know status of steering committee????!!!!!" Frailey 
esqiained that "no one on the committee is responding to his emails." (The Committee had long 
since ceased having face-to-face meetings; and, Gotterbam concluded, even telephone 
conferences had ceased marry months ago.) Frailey was almost ready to "tate unilateral action". 
Here Gotterbam added his own smile symbol and continued, "We have some experience with 
this form of in-action from the Steering Committee." So, Gotterbam was wondering v\tether he 
should suggest that Frailey email the Committee saying that, there being no otgection, he would 
forward the recommendation to the two societies by Valentines Day, "the first conqieted 
deliverable from the Joint Steering Committee." Gotterbam would, in other words, suggest "our 
mode of operation— if he hears no dissent from his committee, Dennis should forward the Code 
and recommendation to both societies." Gotterbam ended this chuckling note with a serious 
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question: "What do you think of this as a recommendation to Dennis? Any suggestion on how he 
should frame his proposal to the Steering Committee to minimize potential dissent?" 

Gotterbam must have reached Miller on one of his dark days. He responded that 
Gotterbam could suggest the silence- means- consent strategy "but I doubt that it would be 
accepted. I think they WANT to do a pocket veto." Miller did not explain who "they" were 
(Cabrera and Frailey, some other members of the Steering Committee, or the Steering 
Committee as a whole) or why "they" would want to do a pocket veto. Whoever "they" were, 
Miller thought the better strategy was to go around them: "request in strong terms, that you or 
the whole exec. Committee be invited to the May meeting and that we get some guaranteed time 
on the agenda." It may be the time "to meet this thing head on instead of out- maneuvering 
them." Gotterbam took Miller's advice, though he waited till April to do it. Meanwhile he tried 
to find out more about the status of the Steering Committee, the likely reception the Code would 
receive at the May meeting of the ACM Executive Council if the Steering Committee remained 
dormant, and the likely reception at the May meeting of lEEE-CS Board of Governors under 
similar conditions. 

11.2 Spring maneuvers 

On March 1, Amr El-Kadi (the professor in Egypt) wrote Gotterbam asking for an update 
"on the response you get from the Steering Committee on V 4.0 of the Code". El-Kadi wanted to 
"know how that ends." He also wanted to know about "the other two task forces: have they 
completed their work" and "in what form would the steering committee merge the work of the 
three task forces?" Gotterbam did not respond until March 16 (apparently using the two weeks 
intervening to leam what El-Kadi wanted to know). The response, a page long, provides a good 
summary of the state of the Steering Committee (and its work) at that time. Though addressed to 
the listserv, it preserved El-Kadi's email at the bottom and began by acknowledging "the 
following questions from Amr". What followed immediately was the wisdom of an experienced 
committee chair: "Life is not simple." Gotterbam then reported that on December 16 he sent out 
"our recommendation" that Version 4 be forwarded to both "the lEEE-CS and ACM," that "both 
societies had meetings of their executive committees in late January and early Febmary", that he 
had received no response from the Steering Committee to the December recommendation, and 
that Version 4 had not been forwarded when he checked in January. He had sent a "follow-up 
letter to the Joint Steering Committee" in January and later "telephoned the ACM co-chair 
[Dennis Frailey]". Frailey had told him that the Steering Committee "had not yet formally 
responded to my (our) request(s)." The Committee had not even responded to Frailey' s requests. 
More phone calls revealed that the Steering Committee's "lEEE-CS chair [Cabrera] has 
resigned" !^^ By the time Gotbertam learned of Cabrera's resrgnatron, it was the middle of 
Febmary and both the lEEE-CS Board of Governors and the ACM Executive Commrtiee had 
met and "we were not on their agendas". Gotterbam "spote with the President of the lEEE-CS in 
March"; she had "asted someone to be the new lEEE-CS co-chair^'.' ^ Gotbertem was still trying 
to find out when the next Board of Governors meeting would be, but had been put on the agenda 
of the next ACM Executive Commitbee meding in the US— in May, in Washington, DC. 

That was the sinqier part of Gotbertem' s administrative life. The email now explained 
some of the conqiicating factors. At least "part of the protiem we are having" seemed to be 
"related to the status of the education and ^Is task force products". The "skills task force" 
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(Body of Knowledge) had "spent a lot of money" but had not finished its work. "Some people" 
wanted to hire a professional group to finish it. Meanwhile, the "education task force" 
(Curriculum) had been "waiting on the skills task force results, but I think that has currently 
changed— along with the leadership of the education task force." Gotterbam then directed 
anyone interested to a website with reports from all three task forces. (The reports there, except 
for SEEPP's Version 4, were then all almost a year old.)^^ The change in leadensihip might not 
end the Curriculum task force's troubles, Gotbe±am added The "U.S. based accrediting 
agency— ABET" had asted the IEEE (but not lEEE-CS) to "define a software engineering 
curriculum". So, it seemed, "there are two distinct efforts going on related to curriculum."'' The 
Steering Commitiee seemed to need more than a new chair. 

Before promising to "teep trying to work through the steering committee", Gotteibam 
reported that he was "doing n^^ best to publicize the Code." He had had some successes. The 
Code had been "adopted by some industries" and will soon "^Dpear in some text books". It is "on 
a web site in Bosnia" and will "appear in some publications" . He was hopng it would become "a 
defacto Standard, [so] that it will be easier for it to get support from the societies." 

While GotteriDam was willing still to work through the Steering Committee, he was no 
longer willing to work through it alone. He had to be prepared for the Committee again to fail to 
do ariything. So, on April 8, he addressed a formal letter— "Dear Charies House [ACM 
President] and Dennis Frailey"." The letter "respectfully requested[ed] that [Version 4] be 
considered at the next Executive Committee meeting in May for adoption by the ACM." A 
similar request was going to the lEEE-CS in time for the June meeting of its Board of Governors. 

That was only the beginning of a letter that went on for more than a page. Its second 
paragr^±i explained that SEEPP had sent the Steering Committee Version 4 in December and 
followed up with another letter in January. (SEEPFs letters of January 19 and December 16 
were apperited in case there was ariy doubt about v\tot they said) "We understand," Gotteibam 
continued, "the Steering Committee' s response has been delayed, owing to reorgardzatiorL" That 
delay had "several unfortunate consequences". One was that the "conpjting community has 
criticized this joint effort as going nov\tere" when in fact there was one, if only one, "finished 
product", the Code. Second, the Steering Committee's efforts were in danger of trailing events. 
At a recent conference at v\Mch licensing software engineers in Texas was discussed, the Code 
"was described as a significant contribution to professionalization and licensing of software 
engineers." Would it not be unfortunate if the Texas Board adopted the Code as their standard 
before it was ^proved by the sponsoring societies"? Third, the Code was already receiving 
"international recognition". That recognition included adoption "by industry such as Siemeris 
Software Development, India"; the Code's publication in several conpjter etiics text books 
("including Kevin Bowyer' s revision of his lEEE-CS book on Corrpiter Ethics"); discussion of 
the Code at several professional meetings; and its forthcoming publication "in the Journal of 
Business Ethics, Jouiiial of Science and Engineering Ethics, the Proceedings of the ACM Policy 
Conference in May (in Washington, DC), and tiie SIGCSE Bulletin,"^" Would it not be 
unfortunate, Gotterbam seemed to ask if, with all this support for the Code, the Steering 
Committee' s inaction were allowed to stop the ACM and lEEE-CS from endorsing it? 

The letter then offered three reasons, each having its own paragraph, for the ACM (and 
lEEE-CS) to endorse the Code. Frrst, the Code had "undergone extensive review by those who 
wiU be affected by its adoption" as well as "by ethics officers of large industries, jliilosophers, 
and ethidsts". Version 4 "represents a general consensus". Second, failure to endorse would 
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indicate "a lack of support for ethical practices", forcing "each software practitioner to re-invent 
the morality of software engineering". Third, the ACM should "take a stand to provide all 
software engineers with an ethical direction and with a tool they can use to educate others- 
including their management— about the ethical responsibilities of the software engineer." The 
Code did what the ACM wanted it to do, "clearly state the moral commitments of practicing 
professionals and of the profession." 

A few hours after sending off this letter, Gotterbam had a response— from Frailey.^^ He 
wisihed that "you had contacted me before sending this [because the] steering committee is 
preparing a recommendation to the two bodies you mentioned" That was good news— even if 
tardy— and more followed There was "consensus, at least there appears to be, that the code of 
ethics part [the short version] is suitable for recommending." Frailey then got to the bad news: 
"there is some concern that the professional practices part [the main code] is not ready for 
recommendation, mainly because some steering committee members fed the field is too 
immature to be recomnoiding such practices." That news raised marry questions. It was Mary 
Shaw (lite Zweben, one of the original ACM-appointed members of the Steering Committee) 
who typically argued from the premise that software engineering was "too immature" a 
discipline to be a profession She had been arguing from that premise for almost a decade. Now, 
even with support at 95% or above for most provisions of Version 3 (and therefore, probably, for 
most provisions of Version 4 as well), she had, it seemed, no second thoughts. She was still 
talking as if there were no consensus on standards of practice. She had, however, (^Dparentiy) 
not remained entirely unmoved She was now willing to accept the "code of ethics" (alttough the 
vote on Version 3 had not included it that is, the "short version"); what she was still not willing 
to accept was the "code of practice" (the main body of the code on v\Mch a clause- ty-clause vote 
had been taten). What part, if ariy, did evidence play in her decision? The oprdon of practicing 
software engineers? Tte "immaturity of the field"? Was she alone in her opposition to the full 
Version 4? Was Frailey again with her? Did she have other allies? ("Some steering committee 
members" sounded like more than one, but perhaps Frailey wished to give that impression 
simply to protect the confidentiality of deliberations.) 

The Steering Committee was (Frailey continued) "trying to work this out" and planned to 
"make a formal recommendation to the two councils in May." Frailey had only been "waiting to 
contact [Gotterbam] further until more members of the steering committee had participated in 
the discussion of the committee's final recommendations." What did that mean— "more 
members"? The Steering Committee was a not large body. It had ten members— not counting the 
ex officios (who were, apparently, not to be part of these deliberations). Or, rather, it had no 
more than nine members until Cabrera was replaced. If Frailey was (as he said) still trying to get 
more members to participate, the consensus he described must be among only a part of the 
Committee, perhaps a small part, a fragile consensus and one in which even one articulate 
member (such as Shaw) might cany great weight. There was, then, still no guarantee that the 
Steering Committee would do anything in time for the May meeting. Frailey was in effect telling 
Gotterbam that the Steering Committee was barely operating— and, therefore, that going around 
it had been wise. Gotterbam' s letter to the ACM might protect his time on the May agenda; it 
certainly had made it harder for the Steering Committee to do nothing or to send just the short 
version of the Code forward. Everyone at the ACM Executive Council would know that SEEPP 
had recommended the entire Version 4, not just the short version, and had done that in December 
(almost five months before the May meeting).^^ Gottertem had, it seemed, out-maneuvered the 
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steering Committee— or at least a minority of it. There might be awkward questions at the 
Executive Council meeting, but at least the complete Version 4 would be in front of them in 
May. He could make his apologies then. 

Having offered Gotterbam some hope, Frailey returned to a subject about which 
Gotterbam had worried since September 1997, the dissolution of the Steering Committee. Frailey 
posed (what he called) "one simple question": "Should the code of ethics activity continue and, if 
so, what bodies of ACM and the computer society should sponsor it?" The Steering Committee 
was going to recommend that each of its sub- activities "be continued, if appropriate, to be jointly 
sponsored by the appropriate bodies in the two societies, with a new 'coordination' body to be 
formed as a replacement for the steering committee". Of course, Frailey' s question was not 
simple. The coordinating body could be a permanent version of the Steering Committee under 
Barbacci, active and helpful, or a presence even more shadowy than it had become under 
Cabrera, or any number of other things— better or worse than the Steering Committee had been. 
Everything depended on the details: membership, budget, powers, reporting line, and chair. 
Though Frailey offered no details (and seemed to have none), Gotterbam could see that the 
Steering Committee's dissolution might not be the disaster he had anticipated. He would have to 
think hard before he answered Frailey' s "simple question". 

A few days later, Gotterbam leamed that Leonard Tripp had replaced Cabrera as Chair of 
the Joint Steering Committee. Though Tripp had been a member of the Steering Committee since 
early 1996, Gotterbam had never met him. (The Steering Committee had held only one face-to- 
face meeting during Cabrera's term (November 1996), holding that one without ex officios- 
except for Melford.) Gotterbam knew Tripp only from one phone conversation back in 1994. 
Melford had called Tripp, one of the "IEEE-Standards gums", during the April 24 meeting in 
DC, to ask about how to write a "PAR" (3.4). A distant voice coming through a speaker phone 
set in the middle of the conference table, Tripp had seemed a tme "organization man".^^ 

Had Gotbedem leamed more of Tripp during the intervening years, he might have found 
much to confimi that first inp:essiorL Though a member of the ACM as well as of the lEEE-CS, 
Tripp had largely confined his professional activities to the IEEE. He had served on the 
Operations Commitbee of the lEEE-CS Technical Council on SofbA/are Engineering, chaired the 
lEEE-CS Standards Activities Board, Standards Coordinating Commitbee, and Software 
Engineering Standards Commitbee. He also chaired the US Technical Advisory Group on 
software engineering sbandards. Had Gotbeitem known all this, he would have had no trouble 
understanding v\^ Melford considered Tripp "Mr. Standards". He might, however, have 
wondered v\^ Tripp took such an interest in Standards. The explanation could not be Tripp' s 
education Both his degrees were in mathematics (Brigham Young University, BS and MS). As a 
mathematician, Tnpp should have gravitated toward ACM activities (and away from Standards) 
rather than toward lEEE-CS (and Standards). What seems to explain his preference for the lEEE- 
CS— and for standards— is his employer. Tripp had worked for the Boeing Company for thirty 
years. Boeing is an engineering organization par excellence, building some of the worid's 
largest, most sophisticated aircraft, both civilian and military. Technical standards, including 
standards for software, are central at almost every step of what Boeing does. Tripp had (like 
many other software engineers) moved from thinking of software as mathematical formulas to 
thinking of it as the most complex of machinery, ethereal but vital. His specialty had become 
standards for safety-critical airborne software. For him, the Standards- setting process was a 
matter of life or death.^* 
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Gotterbam worried about having "Mr. Standards" in charge of the Steering Committee. 
For him, the term "IEEE Standards" meant meetings concerned with PARs, CFPs, the 
Operations Guide, Scopes, and other procedural matters that bored him, produced nothing but 
procedural documents, and seemed to draw nothing but yawns from ordinary volunteers. 
Gotterbam recalled Chikofsky's 1994 warning that the IEEE Standards process could go on for 
"a long time" (3.4). Since that warning, Gotterbam had leamed that "a long time" meant "years"; 
he had himself slaved three years in the salt mines of that complex process.^^ When Mdfoid 
resigned in December 1996, Gotterbam fdt as if chains had been stmck from his legs. He had 
abandoned the IEEE Standards process, replacing it with something lite the sinqie process by 
which the ACM had adopted its code. He had acconplished more, infinitely more substantively, 
in one year in that way than he had in the three preceding years following the IEEE standards 
process. Was all that had been achieved in 1997 to disappear into the endless tunnels of that dark 
process? 

SinceTripp was now in charge, there was nothing to do but to try to work with him So, a 
few days after learning of the Steering Commitiee' s new chair, Gottediam wrote Tripp "a status 
report" cleariy designed to show him that the IEEE process had, in effect if not in form, already 
been satisfied. "We" worted on the code for "almost two years" (counting, it seems, Mechler^s 
efforts in 1996 as well as his own in 1997, but not 1994's procedural activities). There had been 
"a broad based development effort— tmly international in participation— with contributions from 
a wide range of practitioners." Having framed the process in this way, Gotterbam took a page to 
summarize v\tot was already in the December and January letters of transmittal to the Steering 
Committee and in the March letter to the ACM (the reasons to move quickly). That letter is dated 
April 20.^^ 

Eariy Sunday morning, April 26, Gottedem sent Mechler the standard email informing 
him that (in response to his report of a new email address) he had (once again) been added to the 
PRFCMP-L mailing list. A few minutes later Gotterbam added a personal note (apparently, to 
answer Mechler^ s "v\tof s new?"). "[Tiying] to manage a list at another site" is, Gotterbam 
observed, "no fun", but Mechler had not missed any messages. There was news, though. There 
had been "some leadership changes on the steering committee". Gottedem was "working to get 
the Code version 4 in front of both the lEEE-CS and ACM executive committee meetings." 
Then, changing the sutgect, Gottedem asted v\tether Mechler knew "of ariyone using the 
Code." Gottedem knew "of one Seimen's shop, an insurance conpariy, a division of Hitachi, 
one arny training program and that is about all I remember at this moment"" Mechler seems 
not to h^e responded 

Two days later (April 28), Gottedem sent an official letter ('T)ear President House") 
requesting the ACM Executive Council to consider adopting Version 4 at its May meeting. The 
letter exists in two electronic forms. One is ordinary text; but the other is on the lettediead of 
Gotterbam' s Software Engineering Ethics Research Institute.^ ^ Using software just becoming 
available, Gottedem had made his electronic mail as inp^ssive as possible. He sent the letter 
and a copy of Version 4 (as he said in a covering memo) as "support material for the ACM's 
meeting in May". The letter itself indicated he did this on Frailey' s instmctions.^ ^ Though much 
the same as lis earlier letters of transmittal, this one included one new item with the title 
"Software Alliance". The Texas Board of Professional Engineering Licensing Committee was, 
he reported, "considering the Code for their proposed licensing standard for Software 
Engineers". Following that startling news, he listed the Code's recent successes: It was being 
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used in a program for industrialists in Australia, at Army facilities at Fort Monmouth (New 
Jersey) "in training materials for computer engineers, computer scientists, and computer 
specialists", and so on. 

On May 5, Gotterbam heard from lEEE-CS. After several days of "telephone tag", he 
and its new president, Doris Carver (co-chair of the Curriculum task force, 1994-96), had finally 
been able to talk. She later sent an email confirming the substance of the conversation (with a 
copy to Tripp).^° The "proceduieyou will need to follow is for the report to be suhmitied viathe 
steering commitbee". The lEEE-CS half of Gotterbam' s atberrg* to bypass the Steering 
Committee had failed Carver pointed out (v\tet she— correctly— thought Gotterbam knew 
already) that Tripp was the new Steering Commitiee chair. "[The] best path is", she advised, "for 
the two of you to communicate." Gotterbam decided to wait until he knew v\tot the ACM 
Executive Council would do on May 10. If they ^Dproved the Code, he would be in a better 
position to work out something with Tripp. 

By the time Gottertem attended the ACM's Executive Council Meeting on May 10, he 
knew that he had underestimated the Steering Commitbee (or, at least, Tripp). No longer a "silent 
partner", it too had put an item on the Coundl' s agenda^ ' Thou^ titled "Report of Task Force 
on Software Engineering— Software Engineering Code of Ethics & Professional Practice", the 
item was in fact a status report on the work of the Joint Steering Committee. John Werth 
(Carver^ s ACM counterpart on the Curriculum task force, 1994r96) spote for Frailey (v\to was 
absent) . After listing the four purposes for v\Mch the Steering Committee had been established in 
1993, Werth reported that the Engineering Licensing Committee of the Texas Board of 
Professional Engineers had ^Dproached the Steering Committee in 1997 for assistance with "the 
issue of software engineering licensing".^ ^ The Licensing Committee had "formally requested 
that ACM and lEEE-CS jointly work with it to define a body of knov\dedge on which national 
engineering licensing exams [for software engineering] will be based." The Texas Board of 
Professional Engineers would next meet in Fort Worth, June 17-18, and might then enact rules 
for licensing software engineers in Texas. The question for the Council was v\tot to tell the 
Texas Board at their June meeting. The Steering Committee knew at least as much about events 
in Texas as Gottertem did 

The minutes report one Council member or another observing that "coming out as a 
discipline will be a challenge" for software engineering, that there "will be a need for strong 
industry representation", that it was "not known v\teher industry was driving this issue", that the 
Texas Board had already set criteria for licensing disciplines 'less well defined than SE", and 
that software engineering had in recent years changed from a "supporting activity" to a 
"princip[al] player." When the discussion ended, the Council unanimously took two actions. 
First, it declared that the "ACM would be pleased to assist the Board in defining the body of 
knov\dedge and standards of practice on v\Mch such licensing exams would be based [should the 
Texas Board vote to adopt rules for licensing software engineers]." The ACM would also be 
"pleased to work with the IEEE CS in this endeavor." Second, the Executive Council requested 
that "Dennis Frailey or Leonard Tripp, in consultation with other members of the Steering 
Committee and, if possible, including participation from SIGSOFT and the ACM Education 
Board, propose a management stmcture v\tose responsitality would include: 1) coordinating 
follow-on activities of the Steering Committee in the body of knov\dedge, ethics, professional 
practices and education areas; 2) assisting State Licensing agencies...; 3) assessing the 
inqiications of licensing on current software engineering practitioners and ameliorating any 
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negative implications." The proposal was to be brought back to the ACM Executive Council at 
its next meeting Qune). It was now official. Something more permanent was soon to replace the 
Steering Committee (and it would have the power to work with state agencies much as Buckley 
had suggested early in 1993). But what that something would be remained to be decided— and it 
would be decided not by the Steering Committee as a whole but by Tripp and Frailey (after 
"consulting" with the Committee and others). Apparently, Tripp and Frailey were to have a free 
hand; the Steering Committee was already (more or less) dead. 

The ACM Executive Council, fifteen members present met on Sunday at Washington' s 
Renaissance Hotel from 8:30 AM to 4:10 PM {May 10, 1998). The part of the neeting devoted 
to Werth' s report the subsequent discussion, and the two motions was (judging by the minutes) 
about one thirteenth of the v\tole (30-40 minutes). A slighfly larger part concerned Gotterbam' s 
repoit The time set aside for the Steering Commitiee at this meeting (that is, for Frailey' s report 
as well as Gottertem's) was more than a quarter of the v\tole, evidence of the inpjrtance the 
ACM assigned the Committee' s work at this time.^ * 

Gotterbam began his presentation by explaining that the Code was a set of standards fora 
"sub-specialization" within the ACM and lEEE-CS, that the proposed draft (in one version or 
anotha:) had been published on the web, in lEEE-CS's Computer, and the ACM's 
Communications, with a ballot to be returned, and that most provisions of the code had received 
a 95% approval in the balloting that followed. Gotterbam asked the Executive Council to 
approve the Code more or less as it had approved the ACM Code six years before. 

The discussion that followed did not go as Gotterbam had expected. He soon leamed that 
the Steering Committee had made its own recommendations concerning Version 4: Version 4 
was "ready for review in a formal process". The process "should include balanced selection of 
representatives from software practitioners, educators, producers, and users" and "should follow 
the principles of due process such as those used in standards development"^^ Upon conpletion 
of the formal review, the Code would be "suitable for consideration by the ^Dpropriate bodies". 
The "^Dpropriate committees of ACM and IEEE CS" should conduct the forrnal review. It was 
this motion, as Gotterbam leamed after some confusion, not his, that the ACM Executive 
Council officially had before it^^ Gotterbam also leamed that Tripp was now lEEE-CS's 
President-Elect (that is, the President for 1999). "Mr. Standards" was now formidable indeed 

The rest of the discussion, though surprisingly peripheral, probably made the Executive 
Council hesitate to do ariything definitive. One Council member, noting that the Code did not 
define "software engineer", asserted (perh^:s in answer to Gotterbam' s description of software 
engineering as a "sub-specialty") that in Europe software engineering was "an integral part of 
Conpjter Science". Gotterbam did not deriy that but reported that in Europe, or at least in 
Britaia conpjter science was itself considered part of engineering. That answer may have 
suggested the next question: If the ACM Code of Ethics is for confuting, v\^ have a separate 
code for software engineering? How is software engineering different? (The inplicit premise of 
the question seems to be that a "sub-specialty" may, or may not be different enough from the 
broader discipline to need its own code of ethics.) Gotterbam responded that the Code "contains 
practical details of v\tot mates SE an ^Dplied science". The response seemed to satisfy the 
Council on that question; the questions that followed were about the consistency between the 
Software Engineering Code and the ACM and IEEE codes. Had ariyone chected for 
consistency? Gotterbam could not say that anyone had but tried to dispose of ariy worry by 
pointing out that the Code' s "purpose is to help the profession and not only ACM' s membership 
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[the purpose of the ACM code]". The two codes did not apply to the same people. There was 
nonetheless agreement that a check for consistency should be done before the Executive Council 
approved the Code. Eventually, the Council unanimously asked COPE (the Committee on 
Professional Ethics) to "review the proposed [code] for compatibility with the ACM Code... and 
to determine the appropriate further process, if any, prior to adoption by the Council." At that 
time, COPE had three members. One was Robert Riser, one of Gotterbam's colleagues at ETSU; 
a second was Keith Miller (a member of SEEPP's Executive Council); and the third, the chair, 
was Gotterbam himself. ^^ The Council had postponed ^Dproval but had refused to decide 
between Tripp and Gotbeatani Lite the lEEE-CS President, it had, in effect, told GotteriDam to 
woric things out with Tripp. That was not the worst outcome imaginable but— as Gotierism later 
said— "It was not a h^Dpy momerit for me."^ ^ 

11.3 Super-fast Standards pnxess? 

Gotterbam rr)w had no choice but to talk to Tripp. This he did soon after returning to 
Tennessee (probably early May 14).^ ^ The phone corwersation began with Gotterbam having no 
idea what to expect He did not even know v\teher Tripp favored or opposed the Code. Yet, 
Gotterbam's first irrp:ession of him was favorable. Though soft-spoloi, Tripp cleariy knew 
v\tot he was doing and was business-lite about doing it He saw his job as supporting the 
production of the best— "most effective"— code possible. He had the same commitment to the 
Steering Committee's other task forces. Curriculum and Body of Knov\dedge. He wanted to 
mate software engineering a profession Following the IEEE Standards process was part of 
doing just that The Code would not have much chance within lEEE-CS if anything ht that 
process were followed Engineers do not lite to adopt Standards ad hoc. Tripp did not however, 
expect the adoption process to tate years. He had overseen the adoption of marry Standards. He 
saw no reason v\^ the whole process for Version 4, including ^Dproval ty the lEEE-CS Board 
of Governors, could not be conqiete ty airturrai The cmcial st^ was getting the ballots out 
Once they were out the process would have a schedule— and automatically produce "closure" ty 
a fixed date. Of course, to get the ballots out "we" (Gotterbam and Tripp) would have to 
develop a balanced list of reviewers, people v\tom both lEEE-CS and ACM members would 
respect as individuals and who, as a group, constituted a fair representation of the relevant 
constituencies. But Tripp had a staff experienced in devdopng balanced review groups, lists of 
potential reviewers, and so on If Gotterbam would prepare a preliminary list including everyone 
he thought might be appropriate, Tripp would add v\totever was missing. Tripp wanted the 
invitations to participate in the review group out ty the end of May.* ° 

By the time Gottertem hung up, he fdt relieved and tired He fdt relieved because Tripp 
had seemed someone he could work with— conq^etent calm, with his heart in the right place— 
and because Tripp had an experienced staff to do much of the work The nearest Gotterbam had 
come to that sort of support was a student or two. Gotterbam nonethdess fdt tired after the 
corwersation because he had not planned to devote his summer to getting the Code through the 
IEEE Standards process. He had promised to write several p^:ers, had an NSF grant proposal to 
prepare, and was teaching summer school. He fdt tired too because he doubted that ariything as 
corrqiex as the process Tripp described could be carried through as quickly as Tripp said it 
could* ' Everything in Gotteibam' s experience told him to double or triple the time estimates on 
a project lite that But Gottertam had no alternative. If the Code vvere ever to be adopted, he had 
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to do as Tripp said. Gotterbam quickly phoned Carver (lEEE-CS President) that he was working 
with Tripp. 

A few minutes later, Tripp emailed Gotterbam a one- page draft of "guidelines" and a 
draft ballot (with "15 July 1998" as the deadline for the end of balloting) .^^ Later that day, Tripp 
also sent a draft 'Invitation to Ballot' (with "1 June 1998" as the date to send it out). The anival 
of these documents seemed a good omen The next morning Gottertem wrote "Leonard", 

Boy do I lite your efficiency!" The process you outlined looks fine. I have attached the 
three files you sent to me with some suggestions for modificatiorL Let me know v\tot you 
think. 

I am still devdopng a list of ballot invitees. I should have it in you[r] hands by Monday 
[M^ 18]." 

Beneath Gottertem' s signature (the usual 'T)on") were "Comments on the three documents". He 
had used "the comment function of word [MSWord]" to insert specific comments (another 
innovation in software). Anything he wanted to delete was in hractets and additions in quotes. 
He thought it inpjrtant to use the version number of the Code since some of those voting on this 
version may have voted on Version 3. All references to the Code should be c^talized He had 
some questions about the list he was preparing: "Are we still going with the categories of interest 
being: User of software engineered product!;] Producer of software engineered produdf;] 
General (both user and producer)?" He wondered how to identify "Professional Engineers" (that 
is, licensed engineers). He even wondered what the official name of the Steering Committee is. 
(At the end of the Invitation, Tripp had refened to the committee he chaired as the "Software 
Engineering as a Discipline Steering Committee" after getting the name right at the beginning.)* * 

Within a few days, Gotterbam sent Tripp about 270 names (with email addresses) drawn 
from (as he said in a note to himself) "various computer societies, cross section [of] people 
involved with licensing, Consultants, Academics, Professional Engineers, Consumers 'shrink 
wrapped'. Custom software [users], anyone who responded to code, people from insurance 
company, Hitachi, Croatia, peter neuman."" 

A few days after that, on May 26 (four days ahead of schedule), Tripp emailed the 
official invitation to participate in the balloting. It came from "Leonard L. Tripp, Chair, Joint 
Steering Committee for the Estatiishment of Software Engineering as a Profession", went to 
more than two hundred recipents addressed as "Dear Colleague", and had as the sender' s email 
address twoods(a)conpjter.org (evidence, to those v\to knew about such things, that Tripp had 
staff support at lEEE-CS' s Washington headquarters). The letter began with an invitation from 
the 'IEEE Con^Duter Society and ACM" to patrdpate in the "formal review of version 4 of the 
Software Engineering Code of Ethics and Professional Practice." (The mention of ACM, and the 
inclusion of prominent ACM names on the list, was, it seems, intended to mate a separate ACM 
ballot of men±)ership unnecessary.) The letter briefly explained how the Code fit into the larger 
effort, begun in "November of 1993", to establish software engineering as a profession, 
concluding with the significant statement that the SEEPP task force "has conqieted its work and 
recommends that the Code be reviewed by a pand of peers using a formal review process."*^ 
The Code (Tripp continued) "addresses both the responsiMities of the practidng professional 
and of the profession". "We" (Tripp, SEEPP, the Steering Committee, or perii^DS dl) bdieve that 
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the societies "representing the profession" should "provide all software engineers with an ethical 
direction and with a tool they can use to educate others— including their management— about the 
ethical responsibilities of the software engineer."'^^ 

HcRdng set a high tone, Tripp explained v\tot participating in the "balloting group" 
entailed The balloting group "will have 20 days to review and respond to the draft code." 
Reviewing the Code would be demanding: 'The draft code is 7 pages long." The twenty days 
would probably be between June 22 and July 15, 1998. If interested, "you" should fill out the 
form at http://adacon5x1ter.org/Ballot/Index.htm ty June 12. By filling out that form, "you 
certify that you understand the sutgect matter of the proposed document and are technically 
conpetent to cast a bailor Filling out the form also means "you agree to respond in the specified 
period". Responding in time would be inpjrtant The ballot would not be valid unless "at least 
60% of the ballots sent [out]" were returned in time. For that reason, "members of a balloting 
group had an obligation to respond" The next to last paragr^±i provided further administrative 
detail (and directed all questions to 'Tracy Woods, Volunteer Services Coordinator, lEEE-CS"); 
the last paragr^ii sinply thanted the reader for "your time and participation" . 

Mechler received this irMtation just before 6 PM on May 26. The next day, about noon, 
he received a short but hopeful follow-up message from Gottertem (sent through the listserv) : 

You have all probatiy received an "IrMtation to Bailor. This is the last formal step in 
processing the code. I hope you will all volunteer to be part of the balloting group and 
vote. The entire process— setting up the balloting group— sending [out] ballots, 
responding to negative ballots, producing a formal recommendation from the steering 
committee— is scheduled for conpletion ty September— 1998! 

Around the worid, others irwolved in software engineering were receiving Tripp's 
message— and some were also receiving GotteriDam's. But at IIT, only Bumstein received 
Tripp's message— and, apparently, no one received Gotteatem's. At least, we have no record of 
GotteriDam's follow-up— or, indeed, of smy other messages sent through the listserv in 1998.*^ 
This is odd because GotieriDam and I were still corresponding all through 1998. Indeed, the day 
after he sent his follow-up message (May 28), I thaited him for "written comments" on an 
article he was "writing" for CSEFs newsletter Perspectives. Gotterbam did not actually have 
time to write what I wanted. So, I interviewed him by phone, wrote up the interview as an essay 
of about 1500 words, and sent it to him for corrections, additions, and approval. (We had 
discussed the draft by phone, but he had also sent written comments.)" My note continued 
"Some of the information [in the article] may also be useful later— if I ever get around to doing a 
book on professional codes, with your experience as the central exanqie— an enormous success 
if the ACM and IEEE ever ^Dprove the code." I then promised to teep him informed concerning 
plans for v\tot became this book "not least because I would want to do some interviews to fill in 
the marry holes in the process as I know it— and to provide a useful step-ty-step handbook of 
how to do it [write a code of ethics]." I cannot tell v\tether this letter was faxed or carried to its 
destination on a human shoulder. What seems probable is that I did not use email. Though the 
header includes an email address for Gotterbam, it is an address that, ty May 28, 1998, was 
almDst a year out of date (Gotteri:am@ACCESS.ErSU.EDU). Communication between SEEPP 
and irr (though not between Gotterbam and me) had broten down— again 
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11.4 The Vote 

The breakdown of communication between SEEPP and IIT is one indication that 
selecting the balloting group may not have gone quite as planned. There were others. On May 
27, Laurie Wertii responded to Gotterbam's email: "I leave town on June 6 and return on Aug 
5—1 fear that this will disqualify me unless I could vote before I leave. Is this possible?" We 
have this email because it survived in Mechler's files.^° It did not survive in Gotbertem's even 
through Werth sent it through the listserv. There is an explanatiorL In response to the writing of 
this book, GotiEibam asked the ETSU system for a copy of his emails. What it did instead was to 
copy only the headers for 1998, deleting as it did all tte content of the corresponding emails.^ ' 

Mechler ^Dparenfly thought that the pool of potential voters should be as large as 
possible. He therefore forwarded the letter Tripp had sent him to ariyone he thought should vote. 
Mdcher^ s cover memo would say (something Ute): 

Received the invitation to ballot below and thought you may be interested Yesterday I 
was on the web and applied It looks lite ariy one v\to visits the site or goes to it through 
IEEE CS site can ballot Here are the web sites for the committee and the code if you 
want to look ahead of time.^ ^ 

Was Mechler alone in sharing his invitation? How marry voters eriered the lists in this way? We 
do not know. What we do know is that such volunteers did not invalidate the process. The cmcial 
step in achieving a balanced review panel was the final assembly of the group. The IEEE had 
standards for assuring an ^Dpropriate balance. If too marry volunteered from ariy one group, only 
some of the volunteers would be given a ballot If too few volunteered from ariy group, others 
from that group would be sought^ ^ 

When Mechler next wrote Gottertem, it was not to brag about how marry potential voters 
he had signed up but to report that he "had [on June 29] tried to set confirmation on the list and 
got this response ['you are not subscribed to tte PRFCMP-L list ]." Observing that te seemed 
"not to te set", te asted v\tether te had missed ariything. A few teurs later, GotteriDam 
informed Mechler that te had indeed missed something. Tte "[balloting] process is underway." 
Tte voting role had 192 names on it of v\Mch Mechler's was one. "You will te getting email 
stortly atout tte web site we are setting up for tte balloting." GotberiDam then got around to tte 
problem that had provoted Mechler^ s email. He had just "chected tte prfcnp-1 list and your 
name is listed as rnecMer_edn]Lind(a)ADTRA]SIZNA.COM." So, Gottertem continued, tte 
listserv would not recognize "you" since "you" were using a different email address.^ * Tte next 
morning, Mechler thanted Gottertem "for tte info" and explained tew te came to ask tte 
technical question Gottertem had answered tte day before: "I never look at rr^^ e-mail [address] 
because everyv\tere else I have been, changed jobs three months ago, I ted an internal and 
external e-mail address." But v\te3B te was working now, te "found that I have another one for 
an unknown reason and during a change a couple of weeks ago tte other was used v\ten I 
sen[t]." He was just then "getting it fixed". He apologized for ariy trouble te had caused 
GotberiDam, stetched v\tot "set confkmation" meant (in respjnse to a question from Gottertem), 
expressed satisfaction that tte balloting was beginning, arid concluded with details of tew his 
lEEE-CS email address forwarded mail to tte address te was actually using.^ ^ 
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The next morning (July 1), Mechler received Tripp's second "Dear Colleague" letter. 
This one informed him that he had been "selected to participate in the formal review" of the 
Code ("based on your response to our original Invitation to Ballot email in May"). Then, after 
taking a paragraph to repeat the history of the Steering Committee, Tripp instructed Mechler to 
go to a certain lEEE-CS web site where he would find three items: 1. Ballot Guidelines; 2. the 
Code; and 3. the Ballot Form. Tripp suggested taking "a moment to carefully read the Guidelines 
before proceeding to read the actual [Code]", referred all questions to "Tracy Woods at lEEE- 
CS", and stated that the deadline for return of the ballot was "Monday, 20 July 1998". The last 
two paragraphs were identical to those in his letter of invitation.^^ Tripp did not say it but those 
who had tept his first letter could see that balloting was not quite on schedule. Tripp had said 
that it would (probably) tate place between "]une 22 and July 15, 1998". It was now scheduled 
to end five days beyond the bracteted dates. 

Qn July 10, Woods sent out a "reminder^' that the "deadline to respond to the Code of 
Ethics is Monday, 20 July", stressed the inportance of getting a response rate of "at least 60%", 
and then pointedly reported that (half way through the twenty days of voting) "we have only 
reached 22%". She urged those with a ballot to "respond even if your vote is an abstention". 
Bdow her note she had helpfully placed Tripp' s July 1 letter giving instructions on how to vote. 

Eariy in the afternoon of July 20, the last day of voting, Mechler emailed Woods, "Did 
we mate it???" Just after 8 AM the next morning, she replied, "Yes, as of Monday morning we 
had a 66% response rate. More came in throughout the day and overnight." The final response 
was 77% (148 out of 192 possible).^ ' The vote was valid 

The votes now had to be counted, comments extracted, and a response devised for each 
comment A conpjter at lEEE-CS automatically took the ballots off the web page, counted 
them, and placed each (including all comments) on a six-column spreadsheet (the first column 
for the nuniber of the ballot the second for date and time received, the third for the voter^ s name, 
the fourth for the vote, the fifth for "comments", and the sixth for "additional comments"). 
Version 4 had done well: 77% (113 of the 148) voted Affirmative, with 45 of those offering an 
optional comment Only one percent (2) had voted Abstain. The rest 23% (33) were Negative. 

Had Version 4 done as well as Version 3? Cleariy, if we conpare only raw percentages, 
the answer must be no. Support had dropped from 95% to 77%. But there are at least three 
reasons to discount such a con^Brison First those voting on Version 4 were not the same as 
those voting on Version 3. They may not even have been the same sort of people. Those voting 
on Version 3 consisted largely of lEEE-CS and ACM members v\to received the relevant 
society' s general publication, read an article on ethics, and (with no other encouragement) filled 
out an eighty question survey. They paid $100 year to be a member of one (or both) of those 
societies. Though Gotterbam had atten^Dted to bring in some groups (primarily, corporate 
officers) v\to might not fit this (uncommon) profile, he had not systematically ainied at 
"balance". Tripp had The overi^ between those voting on Version 3 and those voting on 
Version 4 could not be more than 27%— and might be as littie as 7%.^ ^ Those voting now may 
well have included marry v\to, though willing to vote yes or no, would not have taten the time to 
fill out the elaborate survey the vote on Version 3 required Those voting now may also have 
included marry v\to voted out of devotion to the IEEE's Standards process, that is, people v\to 
voted because they received a specific emailed invitation It certainly included two vvho, though 
they could not property have voted on Version 3, h^jpaly voted on Version 4, Gotterbam and 
Miller. 
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That is one reason to think the 77% favorable vote on Version 4 does not represent a loss 
of support when compared to the 95% vote on Version 3. Another is that there was no overall 
vote on Version 3; only on individual clauses. For all we know, many people who voted against 
even one clause would, if asked about the Code as a whole, have voted no. There is nothing 
irrational, or even unusual, about one clause in a complex document being a "deal breaker". 
Equally possible is that many who voted against many clauses might nonetheless, if asked, have 
voted for Version 3 as a whole— on the principle that, whatever its defects. Version 3 was much 
better than nothing. 

A third reason not to treat the vote on Version 4 as comparable to that on Version 3 is 
that the voting procedure was different. Those voting on Version 4 knew (or, at least, should 
have known) that their vote and comments would be public (that is, posted on the lEEE-CS web 
site for all to see).^^ Those voting against the Code had to explain their vote (in the comments 
section)— or the negative vote would count as an abstentioa Tliey could not just conqiain; they 
had to propose an alternative (if only deletion of the offending language). They ki^w (or, at 
least, should have known) that if SEEPP accepted their alternative, their negative vote would 
automatically become positive. They would get another opportunity to vote only if SEEPP made 
some change in response to the negative comment but not exactly the change suggested— or only 
offered reasons not to mate any change. Voting negative on Version 4 was part of a conplex 
public conversation aiming at consensus, not a mere survey response (as the vote on Version 3 
had been). Voters might well vote differently in environments so different 

WMle those three reasons seem to mate a strong presun^Dtive case for not treating the 
vote on Version 3 as conq^arable to the vote on Version 4, there is some reason to think that the 
two votes might nonetheless be conpaiable. In a few cases we know how a voter would have 
voted on both versions. Six people— Bumstein, Little, Langfoid, LaRue, Maner, and Mechler— 
voted in favor both times (or, in the case of Version 3, seem to endorse the code in such a way as 
to tell us that, if they had been asted, they would have explicitly endorsed the v\tole); and, of 
course, two more— Gotterbam and Miller— would have done so had they thought to vote on 
Version 3. More interesting are the four— Berieur, Black, Harding, and Sigut— we know to have 
voted no on Version 4 and to have expressed a strongly negative opinion concerning Version 3.^ ° 
All four wrote extensive comments as part of the balloting on Version 4; all conplained of 
earlier suggestions not taten; and none conqiained about anything added between Version 3 and 
4. They seem to have voted against Version 4 for the same reasons they would have voted 
against Version 3. Most interesting of all is the remaining category: those known to have voted 
yes on one version and no on the other That category seems to be en^Dty . We are then entitled to 
conclude that voting on the two versions was conq^arable enough to preserve consistency in 
response. What might conparing the two results tell us? 

It will not tell us that Version 4 had lost 20% of the support Version 3 had We cannot 
know about that without doing a conqmson of all the people in the two voting pools— along 
whatever are the right axes for predicting how they would vote. I do not know how to do that 
What conqmson of the two votes does tell us, if it teUs us anything, is that all the work that 
turned Version 3 into Version 4 probably had little effect (positive or negative) on the support 
Version 4 received The category of yes-on-one-and-no-on-the-other is enpty. Had Version 3 
been put to the same test as Version 4, Version 3 must (assuming the category of vote changers 
really is en^Dty) have received a favorable rating of about 77%. Is the same true of Version 2. 1— 
and even of Version 1.0? That is certainly possible on the evidence we have. Are we to conclude, 
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then, that had Gotterbam teamed up with Tripp in November 1996 rather than in May 1998, the 
whole process could have ended eighteen months eariier? 

Mechler once told me that he thought Gotterbam' s various versions of the Code 
amounted to "moving deck chairs around on the Queen Mary". ^^ He did not mean that the 
succession of vensions was as futile as the prove±aal "moving deck chairs around on the 
[iceberg-gashed] Titanic" . On a ship likely to reach port in a few days, the location of deck 
chairs matters— but, in large part at least, only to the passengers. Their location will not speed 
the ship on its way or delay its arrival by even a minute. In writing codes, as in arranging chairs 
on deck, there is considerable "free play"— affecting the look, feel, and content of the code, but 
not its likelihood of ultimate approval. At least one other member of SEEPP/E holds a similar 
view. According to Jayaram, "He [Mechler] kept us going until we drafted the code (Version 1). 
Everything after that was minor in comparison."" 

Questions about v\tot might have been are, of course, notoriously hard to answer, 
especially in human affairs, and I do not claim to know v\tot would have h^Dpened had Tripp 
ard Gottertem teamed up eighteen monttis eariier. I do, however, ttdnk it worth noting a little 
more evidence that Gotterbam' s successive revisions may not (overall) have inpDved the 
Code' s chance of adoption (however much they may have inpDved the Code) . A number of the 
negative votes cite as one reason (or the reason) for the negative some way in which Version 4 
differs from one or more of its predecessors. So, for example, George Samaras (^5) objects to 
"economic disadvantage" in Clause 1.07. "If the software is too expensive," he reasoned, "it will 
not be used/will not sell." The issue is economic, not ethical. 1.07 made its first appearance in 
Version 2.1 (as the ever- controversial "diversity" clause 2.05). Or, consider the next negative 
vote on Version 4: Wilham S. Junk {4&7) voted no in part because "1.03 ['Approve software 
only if they have a well-founded belief that it is safe, meets specifications, has passed 
appropriate tests, and does not diminish quality of life or harm the environment'] does not seem 
to recognize that there are legitimate applications of software technology that may have negative 
consequences on the quality of life of some individuals or result in some harm to the 
environment." Clause 1.03 is the successor of Version I's 2.02 ("Approve software only if they 
have a well- documented belief that it is safe, meets specifications, and has passed all appropriate 
tests"). The chief difference between the two (or, at least, the difference relevant here) is the 
addition of consideration of "quality of life" and "harm to the environment", the very phrases 
that concern Junk. Junk argues that there are legitimate projects for software engineers, for 
example, a "smart weapons system", that cannot avoid reducing someone's quality of life (the 
target's) or harming the environment (as collateral damage). Junk is nonetheless willing to 
change his vote if (along with changes in some other provisions), the word "substantially" were 
inserted before "diminish" and "harm"." 

We are, however, not entitied to conclude from Junks otgection to 1.03 that the 
executive committee made a mistate ty expanding the coverage of old 2.02 or that it could have 
increased the total vote for Version 4 ty anticipating Junk s amendment It is at least possible 
that some positive votes depend on 1 .03 not being westened in the way Junk suggested Having 
pointed out that possihality, we can say no more. While the executive committee undoubtedly 
had a certain amount of freedom in v\tot it did with 1.03, it did not know— and could not have 
known— how much freedom it had Indeed, even now we do not know that 
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11.5 Can this really be the end? 

Balloting closed on July 20. On July 22, Woods sent Gotterbam the votes and comments. 
Gotterbam suggested removing some personal information from two entries. On July 24, when 
Woods posted the official (slightly edited) spreadsheet on the lEEE-CS website, Gotterbam was 
already at work on his responses. He had to respond by accepting each proposed change, by 
making some lesser change, or by explaining why he (or, rather SEEPP) had left the provision as 
it was. Gotterbam had about three weeks according to Tripp's schedule— and only a few days 
more than that till the start of the Fall Term. 

Gotterbam had at least two reasons not to revise the Code again. First, ninety-three voters 
had put something in the comment section (with twenty of these also making "additional 
comments"). Once these comments were organized into distinct points (with one or more people 
making the same point), each required a distinct response— as well, perhaps, as a revision in the 
Code. Respjndirig would be a Hg job, respjnding in a few weeks, Hgger yet; and carefully 
reconsidering every provision someone challenged, a very hag job indeed 

The second reason Gotterbam had not had to revise the Code again was that Version 4 
had passed the formal review process already. According to Tripp, 60% was the minimLim to 
pass.^ ^ All Gotterbam could hope to do now was raise the positive percentage above the already 
comfortable 77%. There was no guarantee that any further revision would in fact do that. Votes 
gained might be balanced or over- balanced by votes lost. Yet, working with his executive 
committee in a way by now familiar, Gotterbam did much more than the minimum the 
procedures required.^^ By August 6, when he met with Miller and Rogerson at the "Tangled 
Web" conference at Dartmouth College, he had a document sufficiently different from Version 4 
to be called "Version 5.0" and a draft of 185 "responses", explaining what had (and had not) 
been done in response to various comments." The three fourii time during the conference to 
review and revise both documents.''^ Then it was off to Boston to deliver a p^:er on August 10 at 
the Worid Congress of Philosophy. GotteriDam sent Version 5.0 and the comments to Tripp (as 
attachments) as soon as he returned to Johnson City. Tripp acknowledged receipt about 4 PM, 
August 12 (Weckiesday), asking GotteriDam to "resend the second file" (the comments) because 
he could read only tte first fUe (with "version 5" in it). Guessing that the problem was the 
second file' s name, Tripp recommended that GotteriDam shorten the file name to eight characters 
or less before trying to resend^ ^ Tripp concluded this email with a reminden 'TSText step is 
recirculate the revised document and the comment resolution to the balloting group. The target is 
to submit the document and the comment resolution to the leadership of the two societies for 
acceptance." 

On August 31, the 185 responses were published in the sixth column of the spreadsheet 
reporting results of balloting on Version 4.'° On September 9 (fifty days after the close of 
voting), Tripp emailed everyone v\to had participated in the ballotir^ his third 'Dear Colleague" 
letter; ' It not only reported the results of the first round of balloting but the results of work done 
since. Thirteen negative votes had been "resolved" (with twenty still "unresolved"), raising the 
affirmative from 77.4% to 86.3%.' ^ It was now time for a "recirculation bailor. The purpose of 
this ballot was to "confirm that comments during the initial ballot have been dealt with in an 
acceptable manner" and also to "increase consensus on the Code of Ethics document" . 

Tripp then directed voters to the ^Dpropriate lEEE-CS website, asking them "to review 
the Code of Ethics (Version 5.0) and to conqiete the Recirculation Ballot"' ^ Those v\to did not 
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wish to change their vote need do nothing. Negatives would remain negative; positives, positive. 
(Silence did not constitute consent, except for those who had already consented.) There were 
only four reasons to change a vote: First those who thought all their objections had been 
"addressed" could change their negative vote to affirmative. Second, those who thought "one or 
more" of their objections had not been addressed could "reiterate [their] negative vote". Third, 
those who wished to "indicate [their] support of objections of another person which have not 
been resolved" could change an affirmative vote to a negative. Fourth, those who thought 
"changes made to the document have introduced substantive problems that did not previously 
exist" could change their affirmative vote to negative. The deadline for responding was 
September 16 (one week from the date this email was sent out). Tripp ended the letter inviting 
"comments on the balloting process", asking that "the questionnaire on the same Web page" be 
completed, and directing any "technical or procedural questions" to his own (Seattle) phone 
number. ^^ 

Qn September 23, Woods issued the final tally. She listed thirty-two voters as originally 
negative." Qf these, only twelve had voted again. Half of these had changed their vote to 
affirmative; half (including Junk and Sigut) had voted negative again' ^ Did ariy affirmative 
votes change to negative? The answerseems to be no, but even Gotterbam does not know. What 
he reported to the listserv on October 13, 1998, is all he recalls today: "I do not have the official 
final word, but 6 of the unresolved negative votes changed to positive so I think the final analysis 
is 132/146 affirmative (90%). That is a passing grade :-)" He then added that the Steering 
Committee would be "presenting the Code to the ACM Council... .this month and to the IEEE 
next month... .It may be a great Thanksgiving."" Seven days later (October 20), he wrote the 
listserv again: "Yesterday the ACM Council met in Vancouver and approved the Software 
Engineering Code of Ethics and Professional Practice (5.1) as their approved Code for the 
practice and teaching of Software Engineering! !!!!!!!!!!" The vote was unanimous. There had not 
even been one abstention. He then added that the "FINAL version" was "on the seen web 
site... .1 am exhausted more later."" 

This email started another listserv party (the first having been almost a year eariier). 
Laurie Werth replied within an houn "congratulations! !" A few minutes later, Norman did the 
same: 'This is great news. Thank you Don for all the hard work and encouragement" Werfh then 
had second thoughts: "Yes, but is it Y2k-con5iiant?" Langford chimed in from England (adding 
below Norman's message): "Hear, hear . .hard taskmaster as he undoubtedly was, Don nursed 
this project to success against considerable odds, and thoroughly deserves congratulations from 
us (and everyone else!)". The last to join the party (and perh^:s the one v\to killed it with a 
touch of reality) was Mechlen 

Congratulations Don and condolences for the IEEE meeting. 

Congratulations to the v\tole team 

Has it been deteraiined v\tere the code will reside? 

Maybe success has gone to niy head but is there a next step vve should consider?" 

Amr El-Kadi emailed Gottertem directly two days later (October 22, 1998): 'T[t] was 
exceptional news that we have reached this stage with Code, thanks to your leadership. Ed noted 
there were problems with IEEE, v\tot happened there"?^ ° 
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Too exhausted and exhilarated to write much, Gotterbam had omitted some interesting 
details about what happened at the ACM Council meeting on October 19. He had taken time 
during his presentation in Vancouver to respond to the three issues the Council had raised in 
Washington in May. First COPE had compared the ACM Code with the Software Engineering 
Code and found no incompatibility. Second, the two codes were not in competition. Those 
covered by the two codes overiapped but were not coextensive. Not all ACM members are 
software engineers; not all software engineers are ACM members. Nor was there anything odd 
about one person being subject to two codes of ethics. A Professional Engineer, for example, is 
subject to the code of ethics of both the National Society of Professional Engineers and that of 
his branch of engineering (such as the code of ethics of American Society of Mechanical 
Engineers). Third, COPE had recommended a four-stage approval process (which seems much 
more orderly as described here than it did as it developed): 

A . Develop and revise the Code based on extensive review [completed "July 1997"]. 

B. Have the Code reviewed by the Joint ACM/IEEE-CS Task Force [this had 
included the Fall 1997 publication of Version 3 and ACM/IEEE-CS membership voting 
on it and resulted in the revisions that produced Version 4]. 

C. Use an existing and tested formal review process used by the IEEE for approving 
international technical standards [Version 4 had easily passed that test but, as a result of 
suggestions made during the balloting, had been revised twice, generating Version 5.1]. 

D. Formal adoption of [Version 5.1] by the ACM and Computer Society... as their 
approved code for the practice and teaching of software engineering.^^ 

Though the ACM Council unanimously passed a motion appropriate to stage D (the last), it did 
not ^Dprove precisely the motion Gotbe±iam expected Tie Council ^proved the Code on 
condition an ACM "grammarian" examine it At least one member of the Council was unhappy 
with some split infinitives.^ ^ 

On November 20 (still, technically, a month before the last day of autumn), the lEEE-CS 
Board of Governors also voted to ^Dprove the Code (Version 5.1). But it too had a condition: its 
^Dproval was sutgect to IEEE' s lawyer examinirn the document and determining that approval 
would not cause lEEE-CS ariy legal problems. On Decen±)er 10, the lawyer, Sandra Pfau, 
answered the Board's concerns in a one-page memo to Arme Marie Kelly, Director, Volunteer 
Services, lEEE-CS (Woods' superior). Pfau stressed that standard setting is always legally risky, 
offering this chilling footnote: 

A recent exanple of the extensive lialility associated with association standard s^ng is 
the case of National Spa & Pool Institute of Alexandria, Virginia Due to a $6.6 million 
judgment against the Institute related to a man's life-changing irguries in a 1991 diving 
board incident the institute has had to declare bankmptcy to teep operating vMle it 
^Dpeals. 

Voluntary standards are, however, 'less problematic in the legal sense" than certification 
programs or "product standards". For this reason, "the language included in the code of ethics is 
perteps not as significant as the manner in v\Mch the code is disseminated and publicized" The 
lEEE-CS should "mate it clear v\ten the code is published that it is a voluntary code." More 
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important when the lEEE-CS endorses the Code, it should "make it clear that the endorsement 
goes to the use of the code, not to individuals or companies that claim to abide by the code." The 
distinction Pfau had in mind seems to be between endorsing the Code and certifying (or 
otherwise endorsing) specific practitioners or products. That is indeed an important distinction, 
but not one that divides "voluntary" from "involuntary" codes. Her next sentence (and tiie whole 
paragraph immediately below it) collapses the one distinction into tiie other. While the lEEE-CS 
"can say that it believes that following the code is a good thing, it is not a good idea... to say or 
imply that those who follow or have adopted the code are better software engineers than those 
tiiat have not adopted the code." She was, of course, right that merely (formally) adopting the 
Code would not make one a better software engineer. But, unless everyone involved in writing 
tiie Code was badly mistaken, she must be wrong that following the Code does not make one a 
better software engineer. Of course, it does. That is why the lEEE-CS would— and should— say 
tiiat "it is a good thing" to follow the Code. 

The lEEE-CS Board of Governors bravely took this memo as favoring approval. The 
lawyer had, however, noted one "typo". Having corrected it, along with the faults the ACM 
grammarian had identified, Gotterbam had before him Version 5.2 of the Software Engineering 
Code of Ethics and Professional Conduct, approved both by the ACM and the lEEE-CS 
(11. Appendix). It is hard to know exactly when this happened. But there is a memo that 
Gotterbam sent Tripp on January 18, 1999, in which Gotterbam both admitted his pleasure "that 
tiie Code has passed legal muster" and informed Tripp that "clause 6.13" had been corrected (as 
Pfau had suggested) .^'^ So, the process of approval was corrqiete no later than January 18— and 
periaps a few days before thatjust under a nr)nth later than Tripp had estii^^ 
over five years after Gottedem had met with Barbacd and Mdford in Pittsburgh to organize 
SEEPP. When the great moment came, it was an anticlimax. 
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11. Appendix: 

SOFTWARE ENGINEERING CODE OF ETHICS AND 
PROFESSIONAL PRACTICE 

(Vension 5.2) as leconnnended by the 

lEEE-CS/ACM Joint Task Force on Software Engineering Ethics and Professional Practices and 
Jointly ^Dproved by the ACM and the lEEE-CS as the standard for teaching and practicing 
softw^ engineering. 

Short Version 

PREAMBLE 

The short version of the code summarizes asprations at a high level of abstraction The clauses 
that are included in the full version give exanqies and details of how these asprations change the 
way we act as software engineering professiorials. Without the asprations, the details can become 
legalistic and tedious; without the details, the asprations can become high sounding but enqty; 
together, the aspirations and the details form a cohesive code. 

Software engineers shall commit themselves to making the analysis, specification, design, 
devdopnent, testing and maintenance of software a beneficial aril respected profession In 
accordance with their commitment to the health, safety and welfare of the public, software 
engineers shall adhere to the following Eight Principles: 

1 PUBLIC - Software engineers shall act consistentiy with the public interest. 

2 CLIENT AND EMPLOYER - Software engineers shall act in a manner that is in the best 
interests of their client and enployer, consistent with the public interest 

3 PRODUCT - Software engineers shall ensure that their products and related modifications meet 
the highest professional standards possible. 

4 JUDGMENT - Software engineers shall maintain integrity and independence in their 
professional judgment 

5 MANAGEMENT - Software engineering managers and leaders shall subscribe to and promote 
an ethical ^proach to the nianagenient of software devdoprnent and niaintenance. 

6 PROFESSION - Software engineers shall advance the integrity and reputation of the profession 
consistent with the public interest 

7 COLLEAGUES - Software engineers shall be fair to and supportive of thdr colleagues. 

8 SELF - Software engineers shall partidpate in lifdong learning regarding the practice of thdr 
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profession and shall promote an ethical approach to the practice of the profession. 
SOFTWARE ENGINEERING CODE OF ETHICS AND PROFESSIONAL PRACTICE 

lEEE-CS/ACM Joint Task Force on Software Engineering Ethics and Professional Practices 

Full Version 

PREAMBLE 

Computers have a central and growing role in commerce, industry, government medicine, 
education, entertainment and society at large. Software engineers are those who contribute by 
direct participation or by teaching, to the analysis, specification, design, development, 
certification, maintenance and testing of software systems. Because of their roles in developing 
software systems, software engineers have significant opportunities to do good or cause harm, to 
enable others to do good or cause harm, or to influence others to do good or cause harm. To 
ensure, as much as possible, that their efforts will be used for good, software engineers must 
commit themselves to making software engineering a beneficial and respected profession. In 
accordance with that commitment, software engineers shall adhere to the following Code of Ethics 
and Professional Practice. 

The Code contains eight Principles related to the behavior of and decisions made by professional 
software engineers, including practitioners, educators, managers, supervisors and policy makers, 
as well as trainees and students of the profession. The Principles identify the ethically responsible 
relationships in which individuals, groups, and organizations participate and the primary 
obligations within these relationships. The Clauses of each Principle are illustrations of some of 
the obligations included in these relationships. These obligations are founded in the software 
engineer's humanity, in special care owed to people affected by the work of software engineers, 
and in the unique elements of the practice of software engineering. The Code prescribes these as 
obligations of anyone claiming to be or aspiring to be a software engineer. 

It is not intended that the individual parts of the Code be used in isolation to justify errors of 
omission or commission. The list of Principles and Clauses is not exhaustive. The Clauses should 
not be read as separating the acceptable from the unacceptable in professional conduct in all 
practical situations. The Code is not a simple ethical algorithm that generates ethical decisions. In 
some situations, standards may be in tension with each other or with standards from other sources. 
These situations require the software engineer to use ethical judgment to act in a manner which is 
most consistent with the spirit of the Code of Ethics and Professional Practice, given the 
circumstances. 

Ethical tensions can best be addressed by thoughtful consideration of fundamental principles, 
rather than blind reliance on detailed regulations. These Principles should influence software 
engineers to consider broadly who is affected by their work; to examine if they and their 
colleagues are treating other human beings with due respect; to consider how the public, if 
reasonably well informed, would view their decisions; to analyze how the least empowered will be 
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affected by their decisions; and to consider whether their acts would be judged worthy of the ideal 
professional working as a software engineer. In all these judgments concern for the health, safety 
and welfare of the public is primary; that is, the "Public Interest" is central to this Code. 

The dynamic and demanding context of software engineering requires a code that is adaptable and 
relevant to new situations as they occur. However, even in this generality, the Code provides 
support for software engineers and managers of software engineers who need to take positive 
action in a specific case by documenting the ethical stance of the profession. The Code provides 
an ethical foundation to which individuals within teams and the team as a whole can appeal. The 
Code helps to define those actions that are ethically improper to request of a software engineer or 
teams of software engineers. 

The Code is not simply for adjudicating the nature of questionable acts; it also has an important 
educational function. As this Code expresses the consensus of the profession on ethical issues, it 
is a means to educate both the public and aspiring professionals about the ethical obligations of all 
software engineers. 



PRINCIPLES 

Principle 1 PUBLIC Software engineers shall act consistently with the public interest. In 
particular, software engineers shall, as appropriate: 

1 .01 . Accept full responsibility for their own work. 

1 .02. Moderate the interests of the software engineer, the employer, the client and the users with 
the public good. 

1.03. Approve software only if they have a well-founded belief that it is safe, meets 
specifications, passes appropriate tests, and does not diminish quality of life, diminish privacy or 
harm the environment. The ultimate effect of the work should be to the public good. 

1 .04. Disclose to appropriate persons or authorities any actual or potential danger to the user, the 
public, or the environment, that they reasonably believe to be associated with software or related 
documents. 

1.05. Cooperate in efforts to address matters of grave public concern caused by software, its 
installation, maintenance, support or documentation. 

1.06. Be fair and avoid deception in all statements, particularly public ones, concerning software 
or related documents, methods and tools. 

1.07. Consider issues of physical disabilities, allocation of resources, economic disadvantage 
and other factors that can diminish access to the benefits of software. 

1.08. Be encouraged to volunteer professional skills to good causes and to contribute to public 
education concerning the discipline. 



Principle 2 CLIENT AND EMPLOYER Software engineers shall act in a manner that is in the 
best interests of their client and employer, consistent with the public interest. In particular, 
software engineers shall, as appropriate: 
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2.01. Provide service in their areas of competence, being honest and forthright about any 
hmitations of their experience and education. 

2.02. Not knowingly use software that is obtained or retained either illegally or unethically. 

2.03. Use the property of a client or employer only in ways properly authorized, and with the 
client's or employer's knowledge and consent. 

2.04. Ensure that any document upon which they rely has been approved, when required, by 
someone authorized to approve it. 

2.05. Keep private any confidential information gained in their professional work, where such 
confidentiality is consistent with the public interest and consistent with the law. 

2.06. Identify, document, collect evidence and report to the client or the employer promptly if, 
in their opinion, a project is likely to fail, to prove too expensive, to violate intellectual property 
law, or otherwise to be problematic. 

2.07. Identify, document, and report significant issues of social concern, of which they are 
aware, in software or related documents, to the employer or the client. 

2.08. Accept no outside work detrimental to the work they perform for their primary employer. 

2.09. Promote no interest adverse to their employer or client, unless a higher ethical concern is 
being compromised; in that case, inform the employer or another appropriate authority of the 
ethical concern. 



Principle 3 PRODUCT Software engineers shall ensure that their products and related 
modifications meet the highest professional standards possible. In particular, software engineers 
shall, as appropriate: 

3.01. Strive for high quality, acceptable cost, and a reasonable schedule, ensuring significant 
tradeoffs are clear to and accepted by the employer and the client, and are available for 
consideration by the user and the public. 

3.02. Ensure proper and achievable goals and objectives for any project on which they work or 
propose. 

3.03. Identify, define and address ethical, economic, cultural, legal and environmental issues 
related to work projects. 

3.04. Ensure that they are qualified for any project on which they work or propose to work, by 
an appropriate combination of education, training, and experience,. 

3.05. Ensure that an appropriate method is used for any project on which they work or propose 
to work. 

3.06. Work to follow professional standards, when available, that are most appropriate for the 
task at hand, departing from these only when ethically or technically justified. 

3.07. Strive to fully understand the specifications for software on which they work. 

3.08. Ensure that specifications for software on which they work have been well documented, 
satisfy the users' requirements and have the appropriate approvals. 

3.09. Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and outcomes 
on any project on which they work or propose to work and provide an uncertainty assessment of 
these estimates. 

3.10. Ensure adequate testing, debugging, and review of software and related documents on 
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which they work. 

3.11. Ensure adequate documentation, including significant problems discovered and solutions 
adopted, for any project on which they work. 

3.12. Work to develop software and related documents that respect the privacy of those who will 
be affected by that software. 

3.13. Be careful to use only accurate data derived by ethical and lawful means, and use it only in 
ways properly authorized. 

3.14. Maintain the integrity of data, being sensitive to outdated or flawed occurrences. 

3.15 Treat all forms of software maintenance with the same professionalism as new 
development. 

Principle 4 JUDGMENT Software engineers shall maintain integrity and independence in their 
professional judgment. In particular, software engineers shall, as appropriate: 

4.01 . Temper all technical judgments by the need to support and maintain human values. 

4.02 Only endorse documents either prepared under their supervision or within their areas of 

competence and with which they are in agreement. 

4.03. Maintain professional objectivity with respect to any software or related documents they 
are asked to evaluate. 

4.04. Not engage in deceptive financial practices such as bribery, double billing, or other 
improper financial practices. 

4.05. Disclose to all concerned parties those conflicts of interest that cannot reasonably be 
avoided or escaped. 

4.06. Refuse to participate, as members or advisors, in a private, governmental or professional 
body concerned with software related issues, in which they, their employers or their clients have 
undisclosed potential conflicts of interest. 



Principle 5 MANAGEMENT Software engineering managers and leaders shall subscribe to and 
promote an ethical approach to the management of software development and maintenance. In 
particular, those managing or leading software engineers shall, as appropriate: 

5.01 Ensure good management for any project on which they work, including effective 
procedures for promotion of quality and reduction of risk. 

5.02. Ensure that software engineers are informed of standards before being held to them. 

5.03. Ensure that software engineers know the employer's policies and procedures for protecting 
passwords, files and information that is confidential to the employer or confidential to others. 

5.04. Assign work only after taking into account appropriate contributions of education and 
experience tempered with a desire to further that education and experience. 

5.05. Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and outcomes 
on any project on which they work or propose to work, and provide an uncertainty assessment of 
these estimates. 

5.06. Attract potential software engineers only by full and accurate description of the conditions 
of employment. 
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5.07. Offer fair and just remuneration. 

5.08. Not unjustly prevent someone from taking a position for which that person is suitably 
qualified. 

5.09. Ensure that there is a fair agreement concerning ownership of any software, processes, 
research, writing, or other intellectual property to which a software engineer has contributed. 

5.10. Provide for due process in hearing charges of violation of an employer's policy or of this 
Code. 

5.11. Not ask a software engineer to do anything inconsistent with this Code. 

5.12. Not punish anyone for expressing ethical concerns about a project. 



Principle 6 PROFESSION Software engineers shall advance the integrity and reputation of the 
profession consistent with the public interest. In particular, software engineers shall, as 
appropriate: 

6.01 . Help develop an organizational environment favorable to acting ethically. 

6.02. Promote public knowledge of software engineering. 

6.03. Extend software engineering knowledge by appropriate participation in professional 
organizations, meetings and publications. 

6.04. Support, as members of a profession, other software engineers striving to follow this Code. 

6.05. Not promote their own interest at the expense of the profession, client or employer. 

6.06. Obey all laws governing their work, unless, in exceptional circumstances, such compliance 
is inconsistent with the public interest. 

6.07. Be accurate in stating the characteristics of software on which they work, avoiding not 
only false claims but also claims that might reasonably be supposed to be speculative, vacuous, 
deceptive, misleading, or doubtful. 

6.08. Take responsibility for detecting, correcting, and reporting errors in software and 
associated documents on which they work. 

6.09. Ensure that clients, employers, and supervisors know of the software engineer's 
commitment to this Code of ethics, and the subsequent ramifications of such commitment. 

6.10. Avoid associations with businesses and organizations which are in conflict with this code. 

6.11. Recognize that violations of this Code are inconsistent with being a professional software 
engineer. 

6.12. Express concerns to the people involved when significant violations of this Code are 
detected unless this is impossible, counter-productive, or dangerous. 

6.13. Report significant violations of this Code to appropriate authorities when it is clear that 
consultation with people involved in these significant violations is impossible, counter-productive 
or dangerous. 



Principle 7 COLLEAGUES Software engineers shall be fair to and supportive of their colleagues. 
In particular, software engineers shall, as appropriate: 

7.01 . Encourage colleagues to adhere to this Code. 

7.02. Assist colleagues in professional development. 
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7.03. Credit fully the work of others and refrain from taking undue credit. 

7.04. Review the work of others in an objective, candid, and properly- documented way. 

7.05. Give a fair hearing to the opinions, concerns, or complaints of a colleague. 

7.06. Assist colleagues in being fully aware of current standard work practices including policies 
and procedures for protecting passwords, files and other confidential information, and security 
measures in general. 
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7.07. Not unfairly intervene in the career of any colleague; however, concern for the employer, 
the client or public interest may compel software engineers, in good faith, to question the 
competence of a colleague. 

7.08. In situations outside of their own areas of competence, call upon the opinions of other 
professionals who have competence in that area. 



Principle 8 SELF Software engineers shall participate in lifelong learning regarding the practice 
of their profession and shall promote an ethical approach to the practice of the profession. In 
particular, software engineers shall continually endeavor to: 

8.01. Further their knowledge of developments in the analysis, specification, design, 
development, maintenance and testing of software and related documents, together with the 
management of the development process. 

8.02. Improve their ability to create safe, reliable, and useful quality software at reasonable 
cost and within a reasonable time. 

8.03. Improve their ability to produce accurate, informative, and well- written documentation. 

8.04. Improve their understanding of the software and related documents on which they work 
and of the environment in which they will be used. 

8.05. Improve their knowledge of relevant standards and the law governing the software and 
related documents on which they work. 

8.06 Improve their knowledge of this Code, its interpretation, and its application to their work. 

8.07 Not give unfair treatment to anyone because of any irrelevant prejudices. 

8.08. Not influence others to undertake any action that involves a breach of this Code. 

8.09. Recognize that personal violations of this Code are inconsistent with being a professional 
software engineer. 

This Code was developed by the lEEE-CS/ACM joint task force on Software Engineering Ethics 

and Professional Practices (SEEPP): 

Executive Committee: Donald Gotterbam (Chair), 

Keith Miller and Simon Rogerson; 

Members: Steve Barber, Peter Barnes, Ilene Bumstein, Michael Davis, Amr El- Kadi, N. Ben 

Fairweather, Milton Fulghum, N. Jayaram, Tom Jewett, Mark Kanko, Ernie Kallman, Duncan 

Langford, Joyce Currie Little, Ed Mechler, Manuel J. Norman, Douglas Phillips, Peter Ron 

Prinzivalli, Patrick Sullivan, John Weckert, Vivian Weil, S. Weisband and Laurie Honour Werth. 

©1999 by the Institute of Electrical and Electronics Engineers, Inc. and the Association for 
Computing Machinery, Inc. 

This Code may be published without permission as long as it is not changed in any way and it 
carries the copyright notice. 



NOTES 

^ Qf course, this "politically correct" and "American" language entered the Code v\ten 

Gotie±)am was woridng in England under the watchful eye of that Scot-patriot Simon Rogenson. 
Gotiedam was then tiying to mate the code "more international". It is remarisahle how different 
from our intentions our achievements can be (or, at least, seem to others) ! 

^ The Dutchman also mentioned (old) 5.06 ("Attract enployees only by full and accurate 

description of the conditions of enployment") in the same sentence, but ^Dparently as an 
exanple of a standard already "aiforced by local law". Gotteri:am\Survey Comments\ 
SLEGERS. Clause 5.05 had begun as 6.10 in Version 1; 5.06, as 6.12. The survey had given 
each a favorable rating just under 94%. Gotteri3am\Version 3\V3 Survey votes. Why had the two 
been deleted? Not all provisions receiving less than 95% had been deleted Some, lite 1.03 (the 
old 2.02), had received only 90% ^Dproval— and would continue to cause trouble. How did 
Gotierbam decide v\tot to revise and what to leave the same? 

^ Interview of Sigut, Septen±)er 27, 2002. His education identifies him as an engineer (strictly 
so called): "I received a Diploma in Engineering in Mechanical Engineering in 1972 (rou^y 
equivalent to an MS) from the Federal Institute of Technology (ETH for Eidgenoessiche 
Technische Hochschule). I began work as a structural engineer in 1972, using computers as part 
of the job. As time went on, writing software became an ever-bigger part of the job, until I came 
to think of myself as a software engineer. There was not then a career path leading to software 
engineering." 

^ Conpare Siguf s comments in the July 20 vote (GottertemWersion 5\RPLY ) : 

Second sentence of the third paragraph of the PREAMBLE to the Full Version says: The 
list of Principles and Clauses is not exhaustive, and should not be read as separating the 
acceptable from the unacceptable in professional conduct in all practical situations. 
When we analyse this sentence, we can say about "the list" that it contains a. Principles 
b. Clauses ... and that it... c. is not exhaustive d. should not be read as separating ... We 
therefore have two distinctive parts of the list, which can be said to have two properties 
each. Let us look at the four possible combinations: 1. The list of Clauses is not 
exhaustive OK, the list of Clauses can of course be continued infinitely. 2. The list of 
Clauses should not be read as ... OK, Necessary condition, otherwise inflexible. 3. The 
list of Principles is not exhaustive... the list of Principles IS the base of the Code. Of 
course, we might later find omissions, but that can be adjusted when we get there. If we 
say NOW that the list of Principles is not exhaustive, we better sit down and think again. 
4. The list of Principles should not be read as ... It is not the Principles, but it is their 
application - embodied e.g. in the Clauses - , which can separate the acceptable from the 
unacceptable. It is not necessary to state that something impossible does not apply. 
Considering the four combinations we can see, that while the properties of the Clauses 
are well defined by the sentence, we can NOT say the same about the properties of the 
Principles. I therefore propose the sentence to be changed to read: The list of Clauses is 
not exhaustive, and should not be read as separating the acceptable from the unacceptable 
in professional conduct in all practical situations. 
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^ Clause 7.06 survived inrhanged through Version 5.2. 

^ Sigut Archive 1-8-98. Sigut resp)nded to Version 4 on January 12. That respjnse is a hat 

over a page long. Most of his suggestions are minor (including several typos to fix), but he does 
"again... plead for" omitting "Principles and" because "while I agree with 'the list of Clauses' 
not being exhaustive, I have strong doubts and misgivings about saying the same about the 
Principles." This time (^Dparently) Gottedem did not respond The otgectionable language 
survives in Version 5.2. 

' This provision is, of course, another one in need of editing: "on v\Mcli . .they. . .propose" 

is ungrammatical. 3.02 sliould read (something lite): "Ensure proper and achievable goals and 
otgectives for any project on v\Mch they work or propose to work" (or perhaps "Ensure proper 
and achievable goals and objectives for any project which they propose or on which they work"). 
This unfortunate sentence survives in Version 5.2. 

^ Zweben' s letter is lost. We have only the response, GotterbamWersion 4\STURESP (no 

date on letter but file date is 1- 19- 1998). Apparentiy, Zweben had suggested "balance" instead of 
"moderate" (neariy an exact synonym). Gotterbam did not explain how this weater provision (in 
either form) was consistent with moving Prindpie 'T*ublic" from third place to first, with the 
claim in the Preamble that the putiic good is "primary", or with various Rinciples requiring that 
serving the client, enqioyer, arid profession stould be done "consistent with tte public interest". 
This language survive into Version 5.2. 

" Indeed, except for its date Qanuary 19), its first paragr^ii, the three sentences of the 

second paragr^±i, sacid the salutation ('T)ear Steering Committee for the Professionalization of 
Software Engineering"), it is identical to the one sent December 16. 

'° GotterbamWersion 4\REC2 (or the identical: Gotterbam\Steering Committee\ 
Recommendation of 4\REC2) . 
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GotterbamWersion 4\REC2. 



GotterbamWersion 4\E*rogress. The letter nonetheless carries "19 January 1998" as its 
date (and that is also the file date). GotterbamWersion 4\REC2. 

" GotterbamWersion 4\PrDgress. 

'* Cabrera seems to have resigned from the Committee at the same time he resigned as 
chair. There was, it seems, no replacement 

'^ During Spring 1998, Gotterbam used the titie "co-chair^' to describe the chair or vice- 
chair of the Steering Committee, ^Dparentiy slipping into the language of his own early days 
working as one of SEEPF s two "co-chairs". 
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^^ The site www.coirpjter.oig/tafc/seprof still existed on Marcfci 16, 2003 (without any 
ofc^dous updating from five years fciefoie). Everything at that site, except Version 4, dated from 
Marcfci, 1997, another sign that the Steering Committee fciad fceen disintegrating for almost a year. 

' ' According to Gerald Engd (then co-cfciair of the Curriculum Task Force), things were not 
as fced as Gotterfciam thougfct ABET' s request concerned accreditation criteria (something much 
less detailed tfcian a curriculum). Tfcie work of tfcie Curriculum Task Force would fce (more or less) 
independent of v\tot ABET was doing. Engd admits tfciat tfcds is a point liMy to fce lost on 
everyone fciut an expert in accreditation and curriculum 

'^ Cfciaries (Cfcoick) House was tfcien Intel's Science Policy and Society Inpact Director. 
Before joining Intel in 1995, fcie fced fceen President of Spectron McroSystems, a v\tolly-owned 
sufcsidiary of Dialogic, focusing on distance learning and "comer conference room" 
enfciancements. He fced long fceen active in tfcie IEEE as well as in tfcie ACM (at one time serving 
as an IEEE Vice-President for Pufciications). www.cpdogi.edu/egm/fcDuse.fcitm (3/23/2004). He 
did not respond to email, classic mail, or pfcone messages requesting an interview. 

^^ GotterbamWension 4\PRESIDAC. I attrifciute the letter to Gotterbam even tfcough all 
tfciree memfciers of SEEPFs executive committee are listed as signatories. Wfcdle not much turns 
on tfcie attritiution, I fed more comfortafcie treating Gottertem as sole autfcor fcoth fcecause tfcie 
letter uses "I" much more often tfcian "we" (tfcough it uses fcoth) and fcecause some of tfcie detail 
(for exanple, events at a conference) seem personal. Wfcdle I am sure tfciat Gottertem cleared tfcie 
letter with Miller and Rogerson, tfciere is in fact no record even of tfcet in tfcie arcfcdves. 

^° Gottertem did not say it, fciut fcie knew afcout these forthcoming publications fcecause they 
were fcds, part of the strategy of dissemination to prevent suppression. See: 'The Uniqueness of 
Software Errors and Tfcidr Inpact on Glofcel Policy", Science and Engineering Ethics 4 (July 
1998): 351-356; "Not all Codes are Created Equal: The Software Engineering Code of Ethics, a 
success story", Journal of Business Ethics 22 (October 1999): 81-89); and "The Ethical 
Computer Practitioner— Licensing the Moral Community: a proactive approach", SIGCSE 
Bulletin 30 Qune 1998): 8-10. "The Proceedings of the ACM Policy Conference in May" were 
printed in a special issue of Computer and Society (with Keith Miller editing it along with Tom 
Jewett). Gotterbam' s contribution was: "Raising the bar: a software engineering code of ethics 
and professional practice", Computers and Society 28 (June 1998): 26-28 (with Version 4 in the 
next section). Gotterbam was then vice-chair (and "Information Director") of the Special Interest 
Group (SIC) sponsoring that journal. If there was an ethics network within ACM, Gotterbam 
was now at its center. 
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Gottertem\Steering Committee\Dennis. 



^^ Would the ACM Executive Council also notice that the short version said it was not to be 
severed from the long version because the short version's "aspirations can become high sounding 
but empty" without the details in the long version? Did Gotterbam now silently thank 
Fairweather for insisting that something be said in the introduction to the short version to prevent 
its being severed from tlie long? 
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^^ Gotteibam Ch^DberlOcmt (September 30, 2004). 

2 * wvvw.(X)npjter.oig/csinfo/lios/tiipp.htm (3/16/2004) . 

^^ "[One] of the things we were warned about using as a model veiy eariy by Elliot C at a 
steering committee meeting was going through this process which normally tates YEARS 
because of infighting by vendors and review processes." Email (Gottedem to Davis), March 17, 
2004. ConpareCh 3.6. 

^^ GottedamWeision 4\Trippl. There is no evidence that Tripp acknov\dedged receipt of 
this report 

" Mechlei\SEEPP98. 

^^ GotteriDamWension 4\A.C]VI2 (with letteriiead) and GotieitiamWeision 4\ACM1 (without 
letteriiead or addressee) . 

^ ^ Apparently, GotteriDam communicated with Frailey again, by phone or email, after April 
8. The archive does not contain that email (or any other to or from Frailey) before the May 10 
meeting (or after). 

^^ GottedemWension 4\Ethics Report (fwd). Carver— and her ACM co-chair— were both 
replaced at the end of 1996. The new co-chairs were Gerald Engd (lEEE-CS) and Rich LeBlanc 
(ACM). They served until the work of the task force was conqieted in 1998. www.acmorg/ 
serving/se^pt9811.htm (3/23/2004). 
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Item 3.2. Gotteri:am\Vei:sion5\acmsupport\POL98MIN. 



^^ For Frailey's overheads for that report, see www.acm.orig/serving/se/min990128 
(4/11/2004), attachment entitled "History of SWECC". Frailey titled this set of overheads the 
Steering Committtee's "Final Report". The overheads report two recommendations. Beside 
recommending "formal review, adoption, and approval processes be followed", it also 
recommended "continuing the code of ethics task force because of ongoing needs in professional 
practices area." 

^^ For details of the report they delivered in October 1998, see 12.1 (and GotterbamWersion 
5\ACMSUPP0RT\ Report). 

^* The Steering Committee's share is even larger if we include item 3.6— an update on the 
integration of the CSAB with ABET. (There is a reference under that item to the Steering 
Committee's task force on Curriculum.) The motion in support of the CSAB-ABET Memo of 
Agreement passed without opposition but with three abstentions. For those wondering what 
"CSAB" stands for, the answer, according to Article I of its Constitution (October 15, 2000), is 
"CSAB Inc." (not, as widely supposed, "Computing Sciences Accreditation Board"). 
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^^ The irdnutes attribute the substance of this paragraph to the 'TF" (presumably, the "task 
force", not 'Tripp and Frailey"). Gotterbam fhrris the minutes should have said "Steering 
Committee". Email (Gotterbam to Davis), March 17, 2004. There are, however, at least two 
explanations of 'TF" that would not reduce it to a mere recording error. One is that the Council 
rnen±)ers were as urclear about the distinction between the task force and Steering Conirnittee as 
were mari^ of us v\to participated in SEEPFs work The other possihality (perii^:s the more 
liMy) is that the recording secretary was singly echoing fte language of tie Steering 
Committee motion— and that (lite the letter Tripp was to write two weeks later), it attributed the 
request for a formal review to SEEPP (rather than to the Steering Committee) . 

^^ "Council is being asked to formally adopt this Code of Ethics per Leonard 
Tripp's. . .letter. Gottertem suggested that having a long delay for some minor changes to the 
Code is not advisable." 
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www.acmorg/tey.peopl^ar/cope98 ((3/19/2004). 
Email (Gotteri:amto Davis), March 17, 2004. 



Gotterbam does not recall the exact date, but it was probably May 14 (Thursday) 
because, on that date, both Gottertem and Tripp seem to have opened their first files concerned 
with balloting— at about 11:34 AM (PDT). See, for exanqie, GottertemWension 4 IEEE 
Vote\aBallot_ethics. Why did Gottertem not contact Tripp earlier that week, say, late morning 
or eariy afternoon, Monday, May 11? That would seem to be the most liMy time for Gotterbam 
to call Tripp, the first working day after Gotterbam' s meeting with the ACM Executive Council. 
Gotterbam now had every reason to move quickly. The only reason for him to wait even till mid- 
day on Monday to call was that he, in EDT, woiid have been calling Seattle, in PDT. Of course, 
that he called on May 11 is one thing. That he actually reached Tripp right away is another. 
There may have been several days of "telephone tag" (as with Carver), ending on Thursday 
morning (May 14) . That would esqplain v\^ nothing h^Dpened until May 14^and then v\^ a lot 
happened very quickly. 
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Email (Gotterbam to Davis), March 21, 2004 (attachment). 
Email (Gotterbam to Davis), March 21, 2004 (attachment). 



GotterbamWersion 4 IEEE Vote\Ballot The originals of the other two seem not to have 
survived Since Gotterbam had begun to use attachments, v\iien he saved a revised version, he 
would have wiped out its predecessor {vMle preserving original file information) . 

" GotterbamWersion 4 IEEE Vote\ABALRSPl. 

' ' GotterbamWersion 4 IEEE Vote\aIrMtcmL 

*^ GotterbamWersion 4 IEEE Vote\AAVOTERS. This is an intemiediate Ust What seems 
to be the final Ust is: GotterbamWersion 4 IEEE Vote\AAVOTOUr. The covering memo 
(addressed to 'Teonard") reads: 
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Here is a text file of addresses of possible balloters. It includes names from several email 
lists related to software engineering and some related to ethics. It also includes the ethics 
officers from some Multinationals, e.g. Higgins from Boeing. Twenty six of the emails 
are for the SEEPP task force members. 

This file was, it seems, opened on May 14, about 3:45 PM (and so must have been revised after 
the May 15*^ email in which Gotbeibam asked advice. (Yes, Bumsbein, Weil, and I are on this 
list— with the right email addresses.) 

^^ This was, of course, technically inaccurate. Neither SEEPP as a v\tole, nor its executive 
commitbee, had recommended a formal review pnxess; it was the Steering Commitbee that had 
done that, with Gotbertem eventually going along. What SEEPP (or, rather, its executive 
commitbee) had recommended was that the executive bodies of the two societies appove the 
Code without delay. 

^^ I point out the use of the personal pronoun "we" here because that is its only use in a 
document that otherwise seems to speak in the name of the "IEEE and ACM". 

*^ irr's archive seems to have stopped receiving messages through the listserv sometime 
after December 18, 1997. This does not seem to have been caused by any change of address. I 
was receiving email from Mechler as late as July 7, 1998, at csep(a)chariie.acc.iitedu (and 
Gotberiam' s May 14, 1998 list gives the correct addresses for eveiyone at IIT) . 

" Donald Gotberiam, 'Two Conpjber-Rdabed Codes", Perspectives on the Professions 19 
(Fall 1999): 4-6 The whole issue was alDOut writing codes of ethics. 

'' Mechlei\SEEPP98. 

^' Email (Gotbeibam to Davis), March 17, 2004. Gotbertem added, "I did not consider the 
headers useful so I deleted them" So, we do not know even how many emails we should look 
for. 

^ ^ Mechlei\SEEPP98. There are at least three of these emails: two on 06/05/98; and one on 
06/15/98. 

" Conpare Gotbeibam: 'Tor all I know 100 people from Microsoft could have wanbed to 
ballot but oriy two, that I know of, were on the official balloting group. (I don't know the rules 
or how it is done but they are veiy scrupulous to have a broad group.) They ^Dplied the same 
techniques for ballot group selection as v\ten they are dealing with major technical standards lite 
a communications protocol." Email (Gotbertem to Davis), March 21, 2004 (attachment). For 
Gotberi:am, the IEEE Standards prc)cess is a blackbox. 

^ * Mechlei\SEEPP98. Gotberi^am then went back to the sutgect of v\tot Mechler might have 
missed concerning SEEPP, repeating information he had already given Mechler several weeks 
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before: "I am working with the president elect of ieee-cs [Tripp] to follow their procedures for 
doing the ballots— following out their formal process." 

^^ The address problem was not "fixed". On July 10, Mechler again wrote Gotbe±iam about 
it (in an otherwise joking note): "I voted yesterday, guess v\Mch way? Attached is a WORD 6.0 
of the short version [of the Code?] suitable for framing, vertically or horizontally with some 
changes in margins. It fits nice in a 8x1 1 frame in my office. If you want you can pass it around, 
I am still having trouble with my e-mail address." Mechler\SEEPP98. 

"^^ Mechler\SEEIT98. "Gotterbam\History of SE Code\History expanded" gives the date for 
the end of balloting as July 15 (periiaps relying on Tripp's original schedule rather than the final 
one). 

" Or, perii^DS, the number should be 146. Two balloters (Samaras, M.2 and ^4, and 
Swearingen ^14 and ^35) each ^pear twice in the list of 148. Gotte3±)am\1998\IEEE vote 
replies. But the covering memo also lists "Robert J. (Rob) Schaff" (sic) as having voted twice. 
He is in fact not listed even once among the 148 (though "Schaaf" does appear as #75 and #76). 
So, the number actually voting might be 145. Given this range, and because the exact 
percentages do rDt rnatter, I will use the IEEE roirnbers even though they use 148 as the base. 

^^ I reached the low of 7% by going through the balloters names, looking for ariy that 
^Dpeared on ariy of Gotteatem' s lists (not only of eariier survey respondents but of the original 
SEEPP working group men±)ers, correspondents, and so on). I found eleven names (out of a 
possible 148). I found four SEEPP men±)ers v\to might have voted on Version 3 (three of v\tom 
certainly did): Bumstein, Little, Mechler, and Langford I also found six others (not SEEPP 
men±)ers) v\to voted on Version 3 or at least commented on it: Berieur, Black , Harding, LaRue, 
Maner, and Sigut). (That means that ten people— just under 7%— certainly did vote both times.) 
I also recognized three other names not on ariy of GotteriDam's SEEPP lists: Joe Hertert (an 
engineer v\to has become interested in engineering ethics); Judith PerroUe (v\tom Gottertem 
knew, if from no where else, from working on the ACM code of ethics); and Rob Riser 
(Gotterterri s colleague at ETSU and on COPE). Because Gottertem might have urged them to 
vote, they too might have voted on Version 3 (hinging the total to 13, almost 9%). Since there 
were about thirty who voted on Version 3 but had no comment (or, at least, no comment that 
survives with a name attached), including Hertert PerroUe, and Riser, it is possible that the 
overiap could be as high as 40 (10 +30) names (about 27%). 

^^ I have inserted "should have" because we have evidence that at least two voters seem not 
to have realized that comments would be public. One gave his confidential ACM voter number. 
Another, after voting for the Code, mentioned in his comments that he did not find the Code 
helpful in dealing with an ethical problem he faced: 

I have recently agreed to serve as treasurer for niy church. I have been assured that the 
position involves overseeing assistants that are well qualified to perform the clerical parts 
of the job. In particular, the pastor' s wife will do the payroll on bootleg software. 
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Gotterbam had both the ACM number and this story removed from the comments before posting 
them on the lEEE-CS web site. (I have achieved a similar protection of confidentiality by not 
saying which of the 148 was the source of the story.) Gotterbam\1998\IEEE Vote Replies. 

™ Gotteitem\1998\IEEE Vote Replies {4i5, m.1, #18, 4iS2). We have the earlier comments 
from Berieur, Sigut, and Black, but krow of Harding' s only because he refened to them in his 
ballot comments. For Bedeur's, see Ch^Dber 8.7 (including notes); for Siguf s, 11.1. Black's 
comments on Version 3, fourteen pages long, are in GottertemWersion 3\Commenl\Black42. 
Based on them alone, I would not have counted Black as an (overall) negative on Version 3 (just 
a careful reader, thoughtful critic, and devoted supporter of a code of some sort). I count him as 
an overall negative on Version 3 only because he does not indicate, in his explanation of his 
negative vote on Version 4, that airy change from Version 3 affected his vote. The negative vote 
seems to have been his way of making sure Gotterbam at least considered one particular point he 
had made about Version 3 as well as many new comments concerning Version 4. As he said in 
his Interview, October 11, 2002: 

I sent in comments on V. 3 after seeing that blurb. I also commented on V. 4 after 
receiving an irMtation to do so from Donald Gotterbam Most of n^^ comments were on 
presentation, for exanqie, v\^ use the word "third party" in a few places v\ten the text 
would be clearer if it used one or more of the terais already standard throughout the code 
("public", "user", etc.)? Only a few of n^^ comments were substantive. In a few places, I 
ftought they had gone beyond v\tot was appropriate for a professional code, for exanqie, 
by calling upon software engineers to volunteer for civic work [in Clause 1.08]. I lited 
the code overall, especially, it saying that it was intended as "guidelines" to help you 
think through the problems you' 11 face. 

Black does not sound lite a "tme" negative. Nor did Gottedem so consider him The version of 
Black's conmients on 3 that Gotterbam preserved has this header (in bold): "these comments 

ARE WORTH A REVISIT ! DG". 

^^ Unfortunately, I have only memory to testify to the Queen Mary simile. Mechler's 
Interview, June 11, 2002, contains only the following exchange (under Question 8) that makes 
the same point in a less colorful way: 

MD: Did you participate in any of the other versions? 

ElVt I saw them, but I didn't have any problems with them. I sent them around to the 
committees. Really, the only time anyone complained was when the condensed version 
was put out, and that was really the only thing. At that time, and I don't know how 
anyone else felt, but we felt that we did our job. 
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Interview of Jayaram, February 25, 2003 (under Question 17). 
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^^ The oddly named Junk was not alone in making this otgection. Gottedem did not, 
however, follow Junk's straightforward suggestion Version 5.2 now reads: "1.03 Approve 
software only if they have a well-founded belief that it is safe, meets specifications, passes 
^Dpropriate tests, and does not diminish guality of life, diminish privacy or harm the 
environment The ultimate effect of the work ^uld be to the public good" The sentence tacted 
on the end (in violation of the general format of the clauses) seems to be Gotterbam' s response 
to Junk. But it does not seem to me to resolve it (unless one is a utilitarian). There might, it 
seems, be times v\ten we should not diminish quality of life, diminish privacy, or harm the 
erMronment even v\tea all things considered, the public would benefit (a littie). We should not 
do that, for exanqie, v\ten the small puUic benefit is achieved at the cost of substantial harm to 
a few individuals or the environment 

^^ Gotterbam eventually had 185 distinct responses. See email (Gotterbam to Davis), March 
16, 2004 (attachment), ^Dpaientiy, an email to Tripp, giving SEEPFs history through the end of 
1998. The number of distinct responses is given at 8/31 (the end of the formal review process). 

^^ SEEPFs Guide to Operations 4.3.5 (^jparentiy following 1993 IEEE Standards 
Operations Manual) set the percentage necessary for passage at 75%, much closer to Version 4' s 
77% but still on the right side of the line. The Guide also set 75% as the minimum retum rate for 
the balloting to be valid {vMle by 1998 the IEEE was using 60% for the minimum retum rate). 
Gotterbam\94r96 Misc\OPGuide feb96. 

^^ While at work on Version 5, Gotterbam received a cheering email from Prinzivalli: 

Has there been any plans developed or considered about how the Societies (lEEE/CS & 
ACM) are going to disseminate the Code? I have some ideas about this state of the 
project and am willing to work with others of the same ilk to develop the follow- on 
training; e.g. strctures of class room or workshop sessions, Code training session-leader, 
and shared omnibudsman tasks for the Code's Publication and Implementation Plan. 

GotterbamWersion 5\The code and beyond. 

^^ Gotterbam\Hstory of SE Code\Hstory expanded: "8/12/98 v 5 to Tripp". There is a file 
for Version 5.0 with that date on it (Gotterbam\History of SE Code\ SEEPPV5toTrip). The 
corresponding file for comments is dated "8/13/1998" (Gotterbam\History of SE Code\REPLY). 
SERPLYDN (with file date 8/12/1998), though virtually identical to REPLY, seems to be an 
intemiediate document of some sort 

^^ Gotterbam\1998\IEEE vote responses. 

^ ^ GotterbamWersion 5\Leonard lEE [sic] Vote Code of Ethics. 

' ° Not marry of the working documents for Version 5. 1 survive. The only ones I have found 
are: Gotterbam\ by\1998\Vension 4 after IEEE voteVeply Aug 13; and (^Dparentiy identical) 
Gotterbam\ by\1998\IEEE Formal RevieW^Jacques Bedeur committees comments. 
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^^ Qr, perhaps it went to eveiyone v\to had initially been invited to vote, v\teher they voted 
or not What suggests this possitality is a "NOTE" near the end of the letter "A person v^ did 
not respond to initial ballot may not raise otgections to ary part of the draft code of ethics v\Mch 
has not been changed from the initial ballot" They may, then, still otgect to something new- 
even though they did not even vote Abstain the first time. 

^^ While this email continues to calculate percentages for the original vote using 148 as the 
base, it uses 146 (not 145) to calculate the percentage of resolved and unresolved negatives— and 
that final 86.3% affirmative (v\Mchvvouldbe 85.1% using the 148 base). 

Sigut was not at all h^Dpy with this webpage. On September 11, he wrote Woods (in 



73 

part) 



The quality of the "Comment Disposition Report" page is so substandard, 
that I am ashamed to refer anybody to it If you want to see v\tot it could 
look lite, check "htlp//www.awaidethz.clV~sigut/Conirrienthtml". In that 
document I changed my Response (nr.ll) so, that it corresponds to the 
original form, and the spurious enors (OA, OD, !, ...) are deleted As 
a side-effect tiie file is ca 3'320 bytes SHORTER, but that's another 
story. 

Sigut saved the webpage and, following his interview, sent me the file (From Sigut— Software 
Engineering Code of Ethics Comments.doc). The file consists of a brief report and the 
spreadsheet The report is clear, but the (cmdal) spreadsheet is virtually unreadable (though one 
can mate it readable by copying to a blank document and playing with it there). Sigut s file did 
not include the ballot below the spreadsheet though he had a problem with that too: "I do not 
see, how I can 'conqiete the questionnaire on the ... Web page', it being a plain text" 
Apparentiy, even the IEEE has (or, at least had) trouble integrating software and making it do 
what it wanted 

'* The website displayed the following documents: Recirculation Ballot Code of Ethics 
(Version 5.0); Summary of Changes; Comment Disposition Report; Ballot Group Member List 
and Questionnaire. The Summary of Changes has survived (GottedemWersion 5\Changes) as 
has the Comment Disposition Report in something less than its final form (GotierbamWersion 4 
IEEE vote\sevote5a\SEVOTErpl). Among the changes the summary reported were a great many 
concerned with "grammar" (for exanqie, changing "judgement' to "judgment' [undoing tte 
spelling introduced vMle Gotterbam worted in England], "consistent' to "consistentiy", 
"methodology" to "method", and 'literate" to "well-written"). Among the substantive changes 
was the addition of "management of maintenance" to Principle 5, of "maintenance and support' 
to 1.05; the addition of "privacy" in 1.03; the substitution of "uncertainty" for "risk" in 3.09 and 
5.05; the substitution of "Be encouraged to volunteer" for "Volunteer^' in 1.08; and the addition 
of a "non-discrimination" clause ("8.07 Not give unfair treatment to anyone because of any 
irrelevant prgudices"). The difference between Version 4 and 5.0, though significant is tiry 
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compared to that between Version 1 and 2, 2 and 3, or 3 and 4. The IEEE Standards process was 
bringing the drafting process to a close. 

^^ The number had actually been 33, with Schaaf having voted twice. He was now listed 
once. The number should, however, have been 31 because G.M. Samaras is still listed twice 
(unless he is distinct from George M. Samaras). I should add (for those familiar with machine 
politics) that there was confusion at IEEE but no hanky-panky. G.M. changed his vote George 
did not vote this time. GotteriDamWension 4 IEEE Vote\Counts. 

^^ Reading these negative votes is not as easy as it may seem When I interviewed Sigut 
(September 27, 2002), he seemed to lite the Code on the whole. When I asked what he didn't 
like, he produced this list ("based on version 5.2 of the Code"): 

Full version; PREAMBLE; 1st paragraph; 2nd sentence: The text "are those who" could be 
left out. As it is, the sentence can be interpreted as a definition of a "software engineer" 
instead of (as I understand it) an enumeration of the software engineers' contributions. 

Full Version; PREAMBLE; 3rd paragraph; 2nd sentence: It still says "The list of Principles 
[...] is not exhaustive". Apart from my critique, I understood during the interview that this is 
NOT the intended meaning. 

Looking at the Clauses 1.04, 6.06 and 6.13 I ask: "who will protect the Software Engineer 
who reports or disobeys the law"? If the backing is not guaranteed, acting according to these 
clauses (or the given exception) might lead to unpleasant results. 

Clause 1.02: 1 would have chosen "temper" instead of "moderate". 

Clause 2.01: 1 would suggest using "frank" or "candid" instead of "forthright". 

Mechlei\SEEPP98. 
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^"^ Mechlei\SEEPP98. Version 5. 1 differed from Version 5.0 only in "some minor editorial" 
corrections. Gotterbam\1998\ACM Council Response. A Word document conparison revealed 
the following differences: "client or errqioyer" in Principle 2 has become "client and enployer"; 
two sentences in the first paragraph of the Preamble have been revised a hat; tte word 
"quantitative" has been inserted after "realistic" in 3.09; "outcome" in 5.05 has been pluralized; 
"better^' has been deleted from 5.09 ("taking a better position"); the credits have been 
reorganized; and (perteps most inp^rtant) a copyright in the name of the "SEEPP Executive 
Committee" has been added 

'' Mechler\SEEPP98. 

' ° Gotierbam\vension 5\0ctober 23 Passed 

^ ' Gotterbam\1998\ACM Council Response. 
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^^ Email (Gotte±iam to Davis), April 2, 2004. Conqmng Version 5. 1 with 5.2 suggests that 
the grammarian ignored the split infinitives (such as that in 3.07) but suggested changing 
"consistent" to "consistently" in Principle 1, adding a "shall" after the "and" in Principle 8, 
changing "consider^' to "recognize" in 6.11 and 8.09, and other minor changes of the same sort 
The grammarian definitely did not perforai the review for consistency and style I had 
recommended the year before. 

^^ Qn Noven±)er 30, Mechler emailed GotteriDam, "Did IEEE [accept] the code? You said 
they would look at it in November." An hour later Gottertem answered, "ieee-cs ^proved the 
code 'sutgect to legal review' . I thought I would wait on announcing to the group until the legal 
eagle said it was ok. More later." Mechler\SEEPP98. 

^* Email (Gotterbam to Davis), March 16, 2004 (attachment). Actually, the date on the 
memo is "1/18/98" (rather than "99"), an error common soon after the change of year. The 
January memo also includes Gotterbam' s first attempt at a timeline for SEEPFs five year 
history. 
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Chapter 12: End Game, Version 5.2, 1999-2000 

"It isn't that things will necessarily go wrong (Murphy's Law), but rather that they will 
take so much more time and effort than you think if they are not to go wrong," 

- Wolf'sLaw 

12,1 The Joint Steering Committee's happy end 

On November 20, 1998, the Joint Steering Committee presented its "annual report" to the 
lEEE-CS Board of Governors, Prepared by "Dennis Frailey, co-chair and Leonard Tripp, chair", 
the report began by describing five "highlights" of an evaluation of the Committee's operations 
"for the period 1993 to 1997", (The evaluation had been undertaken soon after Tripp took over 
six months before,)^ These "highlights" (under the heading "Committee Reorganization") seem 
to represent the thinking of the Committee, or at least of Tripp and Frailey, early in 1998. The 
first "highlight" was that the lEEE-CS and ACM should "continue the work begun by the 
steering committee." What the Committee was doing was worthv\Mle; it only needed to be done 
in a better way. Second, the Body of Knov\dedge task force would require "professional staff 
support" to finish its work The work had proved too much for a task force consisting entirely of 
volunteers (and specialists they could hire under grants they were able to obtain). The third 
evaluation should be familiar (from 11.2): the "cunent draft of the Code of Ethics" (Version 4) is 
ready "for review in a formal consensus process with a balanced representation in the review 
team". Fourth, there was no reason for the Curriculum task force to wait for the Body of 
Knov\dedge task force to conqiete its work The preparation of "curriculum criteria is reacfy to 
commence". The last "valuation" was a recommendation: that the ACM and lEEE-CS jointly 
spjnsor a "peraianent entity" to cany on the work of the Steering Committee (and, by 
inqiication, that the Steering Committee be disbanded). 

This section of the report ends with the announcement that a "charter for the new 
committee" was prepared in 1998, ^proved by the ACM Executive Council and the lEEE-CS 
Board of Governors, and put into operation The first "Executive Committee" of this new 
entity— the "Software Engineering Coordinating Committee" (SWECC)— had six members 
(listed in alphabetical order). Three of the names are new: Mark Ardis (Bdl Labs), Linda 
Northrop (Software Engineering Institute), and Kari Reed (Department of Conpjter Science and 
Conpjter Engineering, La Trobe University, Australia). The other three are familiars Carver, 
FaHey, and Tripp. Of the six, only one (Frailey) is from the original Joint Steering Committee 
(Carver having been a member only ex officio forthe Committee's first two years). According to 
a working document (September 29, 1998), Frailey was to be "Vice-Chair", representing the 
"ACM EC"; Ardis, to be the ACM member representing the "technical community" (and 
endorsed by SIC SOFT); and Northrop, to be the ACM member representing the "education 
community" (endorsed by the "ACM Ed Board Chair").^ Those labels suggest that the other 
three are the lEEE-CS men±)ers: Carver (lEEE-CS President) representing the lEEE-CS Board 
of Governors; Reed (a professor), representing the "educational community"; and Tripp (at 
Boeing), "the technical community". In fact, when they were listed in the minutes of SWECC s 
first meeting, Tripp was only identified as "Chair". Carver (rather than Reed) was identified as 
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"CS Education" (that is, the representative of the "education community") and Reed (rather than 
Tripp) as "CS TCSE" (the representative of the "technical community").^ 

In its fifty-fifty split between ACM and lEEE-CS ^Dpointees, SWECC's executive 
committee is plainly the Steering Commitbee's successor. It is also the Steering Commitbee's 
successor in having under it "project commitbees" that, at first glance, seem to be "task forces" 
under a new name. In several other respects, however, SWECC is a different entity. First, it was 
to have only six members, roughly half the number of the old (ten-member) Joint Steering 
Commitbee (excluding ex officios), but exactly the number the lEEE-CS Steering Committee had 
before the ACM joined late in 1993. Apparently, ten had proved too large for the purpose. 
Second, though SWECC may have as many project committees as required, it could create them 
only with "the consent of the Executive Committee of the ACM and the Executive Committee of 
the [IEEE-]CS". Each project would have "an approved duration".^ The project would go out of 
existence after that date— unless the ACM and lEEE-CS authorized an extensiorL Projects were 
to find it harder than task forces to go on year after year Third, the chair was to have a two-year 
terai and rotate between the two societies. The first chair was to be from the lEEE-CS (and to be 
^Dpointed by its Board of Governors); the next, appointed by the ACM Executive Council (from 
among SWECC men±)ers); the third, ^Dpointed in the same way by the Board; and so on The 
ACM and lEEE-CS were to be exactly equal in SWECC. Indeed, this equality was to extend to 
the projects. When SWECC "formed a project", it was to create a "committee for its oversight 
with equal membership from the ACM and the CS." SWECC could, it seems, avoid the 
disastrous double-chairing that had neariy sunk SEEPP, but it could (it may seem) never again 
allow an executive committee lite that Gottertem set up in January 1997. The next Gotteibam 
would have to choose an executive committee with an equal nurnber of ACM and lEEE-CS 
men±)ers; the next Patricia Douglas would have to find an ACM co-chair right away; and so on^ 

We should not be too quick to treat this prospective elimination of the "next Gottertem" 
as a condemnation of the actual Gottertem— or as neariy as inpjrtant a constraint as it sounds. 
In fact, the overi^ between ACM and lEEE-CS allowed Gottertem to teep his executive 
committee just as it was when (as we shall see inl2.3) SEEPP became "SEPEP" (one of 
SWECC's projects). Gotteri:am could be a nonber for both "ACM and lEEE-CS", Miller, for 
lEEE-CS alone (though he was also a men±)er of ACM); and Rogerson, a member of ACM (and 
the British Conpjter Society) but not of lEEE-CS, could counter-balance Miller. That preserved 
equality between the two societies— if only technically.' The ease with v\Mch the executive 
committee of SEEPF s successor satisfied the new requirement is a reminder that no one seems 
to have otgected to how Gottertem organized SEEPP. Indeed, his handling of SEEPP earned 
him a "retroactive promotion". Eariy in January 1999, Tripp asked GotteriDam to provide a 
timeline for SEEPP. GotteriDam did as asted, explicitly mentioning his co-chair, Robert Mdford, 
at ^Dpropriate moments.^ Yet, v\ten the Steering Committee published its "History" (in March 
1999), there was no mention of Mdford The history lists Gottertem as "chair^' for the entire 
period, 1994r 98 (as if there had been no reorganization at the end of 1996) . What mates the lack 
of any mention of Gottertem' s co-char seem significant is that the History lists all the other task 
force chairs (all as "co-chairs"), even those v\to (lite Carver and John Werth) had been out of 
office for as long as GotberiDam' s co-chair.^ 

SWECC differed from the Joint Steering Commitbee in another way worth mentiorL The 
purpose of the Steering Committee had been to establish software engineering as a profession. 
That purpose at least suggested that software engineering was not yet a profession. In fact, when 
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the ACM joined the lEEE-CS Steering Committee, it had expressed doubts about whether having 
a profession of software engineering was even a good idea (2.5), apparently embodying those 
doubts in the appointment of Mary Shaw as one of its representatives. SWECC's charter 
suggests that the general understanding of software engineering may have changed between 1993 
and 1998. SWECC's purpose, according to the charter, was "to foster and maintain software 
engineering as a professional computing discipline." While "foster" still expresses doubt that 
software engineering is fully a "professional computing discipline", "maintain" leaves no doubt 
that it is at least in part such a profession (as well as, in part, a "discipline" within "computing"). 
When the ACM Executive Council approved SWECC's charter (and did not appoint Shaw to the 
Steering Committee's successor), it in effect declared that Shaw had lost the argument over the 
professional "maturity" of software engineering.^" 

The Armual Report listed six "Key Events" for 1998, the first two of v\Mch occurred in 
June. The ACM and lEEE-CS agreed to worlc with the Texas Board of Professional Engineers to 
"identify a technical basis for recognizing con^Detency in software engineering" and "[enact] 
rules that recognized software engineering as a distinct engineering discipline." In August, the 
NCEES (National Council of Examtnets for Engineering and Surveying) passed a resolution in 
support of 'licensing software engineering throughout the nation." These first three events, so 
closely bunched, may help to explain v\^ Shaw had lost the argument (for the moment at least) . 
Whatever the ACM or lEEE-CS thought, events seemed to be quickly turning sofbA^are 
engineering into a part of engineering. The only question still open seemed to be how it would be 
done. The next three "tey events" offered a tentative answer. In September, the Industry 
Advisory Board for the Guide to the Software Body of Knov\dedge Project "held its first meeting 
in Mont Tremblant, Quebec". The body of krDv\dedge task force (soon to be known as 
"SWEBOK") was hard at work on the "Guide" that licensing bodies would need if they were to 
offer examinations in software engineering. In October, the engineering accreditation agency 
(ABET) and its con^Duter-sdence counterpart (CSAB) "announced the integration of their 
accreditation services". And, on November 11, the ACM and lEEE-CS jointly hosted a meeting 
to "initiate the update of Corrpjter Curricula 1991". Led by software engineering, conpjter 
science seemed to be moving closer to engineering.' ' 

The Steering Committee's last report ended with two "Project Results" in teepang with 
these events. The first was that the ACM and lEEE-CS had ^proved the software engineering 
code of ethics. (Lite the Guide to the Body of Knov\dedge, the Code provided a basis for 
distinguishing between those v\to should be licensed as software engineers and those v\to 
should not) The second "project result' was that the Curriculum task force had conqieted its 
"model accreditation criteria for software engineering" in November and that the ACM and 
lEEE-CS "education boards" had endorsed them Though the Curriculum task force had started 
much more slov\dy than SEEPP, it had finished at almost the same time. When the Steering 
Committee officially dissolved at the end of 1998, it could tate considerable satisfaction in v\tot 
it had accon^ished Of its four original assignments, it had conqieted two, defining "ethical 
standards" arid "educational curricula" (or, at least, standards for such curricula). A third 
(defining the body of knowledge) was well on its way to conqietion (though it had proved a 
much tagger job than expected). Only the fourth, "a±)pting standard definitions", had been 
abandoned— and only because the Steering Committee had decided that the IEEE already 
provided an adequate definition of "software engineering" and related terms.' ^ The Joint 
Steering Committee might (lite General Wolfe on the Plains of Abraham) "die content". 
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12.2 SWECC takes over 

On January 28, 1999 (in Austin, Texas), SWECC held its first meeting, a nine-hour 
marathon beginning at 8:30 AM, with only twenty minutes for lunch. All six members were 
present (though Northrop was only present by a proxy, Laurie Werth, a resident of Austin).^^ The 
rmnutes, nine single-spaced pages, are full of interesting summaries of past work and plans for 
the future. The minutes have six attachments: "History of SWECC"; "Overview of SofbA/are 
Engineering Standards"; "Report on SWEBOK Project'; "Overview presentation given to Texas 
Board of Prof. Engineers"; "Overview of SWECC"; and a "White p^:er by Dennis Frailey on 
cooperation". (All but the last attachment consist of several pages of overtieads.) All these 
documents (as well as the Steering Committee' s Annual Report) were placed on the web. (Tripp 
seems to have lilffid the sun to shine on v\totever he was doing.) 

We may draw three conclusions from an examination of these early SWECC documents. 
The first is that Frailey and Tripp, but especially Tripp, seem to be the source of most of the 
activity. For exanple, two of tte attachments are Frailey' s ("History" and "White p^:er"); the 
other four seem to be Tripp' s. The minutes identify five "ResponsrMity Areas". Frailey has one 
("Education"); Reed and Northrop share one ("Publicity"); and the other three are Tripp's 
("SWEBOK", 'liaison with Standards", and 'liaison with National Bodies"). 

The second conclusion to draw from the minutes of January 28 is that the Body of 
Knov\dedge is not only Tripp' s focus but also SWECC s (just as it had been for the Joint Steering 
Committee) and, as they believed, integral to the Curriculum project (now "Education"). Much 
of the morning half of the Austin meeting seems to have been informational (with the first 
session devoted to "Overview and History of SWECC Project" and the second to "Relationships 
between SWECC and others). The last session of the morning is, lite the first three afternoon 
sessions (each an academic hour), for 'Tlans". But then there is a short session (twenty-five 
minutes) on "Software Engineering Standards" followed by a long session (fifty-five minutes) 
for 'Heport on SWEBOK Project"— with "Responsitality Areas" and 'Tuture Plans" conqieting 
the day. There was, it seems, no special session for Education, even though all three highlighted 
resolutions of the day explicitly mentioned the "Education Project". SWECC adopted three 
resolutions at the Austin meeting. Two of the three mention Education along with SWEBOK. 
The third, vMle it does not explicitly mention SWEBOK, at least inplicitly relies on its results: 
the undergraduate curriculum is to be the "priority" for the Education Project and that curriculum 
is to include "the core content of the software engineering field" 

This description of v\tot SWECC did at its first meeting suggests the third conclusion I 
draw from the minutes. The Code of Ethics was not on the agenda at all. It was, however, not 
entirely forgotten. It is mentioned once in the minutes— the last item on a list of four "proposed 
projects" (the other three of which are "Guide to SWEBOK", "SWF Model Cuniculum", and 
"SWF Performance Norms").'* The Code of Ethics was also mentioned in several of the 
overheads. Whatever the Code of Ethics was, it was no longer "a problem". 

The next face-to-face meeting was to be in Montreal a half year later (July 13, 1999), 
^Dparenfly because the technical experts worldng on the Body of Krowledge were in Montreal 
(at the University of Quebec). SWECC also scheduled a "teleconference during the week of 
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April 12, 1999." It was, it seems, to be a short; meeting, allowing SWECC to evaluate progress 
on various "action items". 

12.3 B ack in T ennessee 

Meanwhile, Gotterbam was trying to put the Code into the hands of as many software 
engineers as possible. These efforts took three forms: publication, consultation, and organization. 
Typical of the first was the publication in the January 1999 issue of Software Engineering Notes 
(an ACM SIGSOFT journal) of Version 5.2 along with a brief introduction under the title "A 
Positive Step Toward a Profession: The Software Engineering Code of Ethics and Professional 
Practice". Though the article was typical of Gotterbam' s attempts to publicize the Code, 
response to it was not. A letter to SEN'S Editor objected both that the Code was "too vague" and 
that it added "nothing to the existing codes of ethics for engineers". The time had come, it 
asserted, "to move beyond 'motherhood statements' and try to give meaning to the title, 
'Software Engineer', by establishing standards that restrict the use of the title to a proper (and 
probably small) subsetof those who now use it."^^ The Editor notified Gotbedem of the letter as 
soon as he received it, offering to print a response beside it in the next issue (May). For 
Gotterbam, v\tot began as a sinqie article had turned into a crisis. The letter's author, David 
Pamas, was (and remains) one of the "greats" of software engineering, especially among 
software engineers concerned with professional ethics. 

The inportance of Pamas to software engineering was evident in the very issue of SEN 
in v\Mch his letter to the editor ^Dpeared A few pages after the letter is an "ACM Fellow 
Profile" of him, including both a short liogr^±5^ and a three-page interview. A licensed 
Professional Engineer in the Province of Ontario, with a BS, MS, and PhD. from Camegie 
Mellon (all in Electrical Engineering), Pamas held the NSERC/Bdl Industrial Research Chair in 
Software Engineering at McMastens University. He was the author of more than two hundred 
p^:ers and reports, redpent of the ACM Best P^:er Award in 1979, of two Most Influential 
Paper awards from the International Conference on Software Engineering (ICSE), and (in 1998) 
of the ACM SIGSOFT Outstanding Research Award Those interested in software ethics revered 
him as one of the eariy opponents of Reagan' s plan to defend against nuclear attack from space 
("Star Wars"). Pamas resigned from a fedieral advisory panel in protest because "as a 
professional. . .1 must devote some of n^^ energy to deciding v\teher the task that I have been 
given is of benefit to society". He argued that the Star Wars project could not do v\tot it was 
supposed to do, could not be adequately tested even if it could, and would in any case not be 
reliable enough to be worth the expense. He made his arguments in public, stressing that his 
resignation was not sinqiy a "personal" decision but one ariy responsitie professional in similar 
circumstances should tate.' ^ 

Gotterbam' s response to Pamas' letter was four times as long as the letter itself. It was 
authored not by Gotterbam alone, but by Miller and Rogerson as well, with "SEEPP Executive 
Committee" (rather than their academic affiliations) under their names (even though neither 
SEEPP nor its executive committee ariy longer existed).'' Apparently, Gottertem thought he 
needed to speak with as much authority as possible. He also had to treat Pamas with respect, 
vMle explaining how wrong he was. The response justifies the level of abstraction the code 
adopted (v\tot Pamas calls "vagueness") by arguing that the Code is just abstract enough not to 
use standards that are (and are liMy to continue to be) "in flux". A code of ethics should not, for 
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example, require "mutation testing for all mission critical software", though it should require 
"adequate testing" (however a software engineer should understand that term at the time). A 
code of ethics should be abstract enough not to be outdated in a few years. 

A code of ethics should not however, be so abstract as to be altogether "uncontroversial" 
— and the Software Engineering Code is demonstrably not that abstract. Here the IEEE 
Standards process provided evidence of how much controversy there was about the Code: 

In 149 pages of comments developed during the lEEE-CS formal review, the following 
conflicting comments were made by practicing "professional" software developers: add 
the clause "avoid criticism of software engineers', "remove 1.08 ...volunteer professional 
skills to good causes", "...make 1.08 mandatory", "remove references to maintenance", 
"include all forms of maintenance", "...not all jobs require the highest professional 
standards" [and so on].^^ 

GotberiDam attributes this variety of oprdon to "software engineering [being], at best, an 
emerging profession". That, I ttdnk, is a mistate. Diversity of oprdon on such questions is, as far 
as I can tell, characteristic of all professions, even of law and medicine, and has always been, 
periiaps because any substantial number of human beings tend to have a wide range of opinion, 
unless forced to reach agreement ty circumstance. What distinguishes the "fully developed 
professions" from those that are merely "emerging" is sinqiy a core on v\Mch most (but not all) 
agree. In this respect at least, Gotterbarris data seems to show that software engineering vvas, ty 
1999, no longer an emerging profession The Standards process had documented something close 
to ninety percent agreement on the Code as a v\tole (and no opposition to most provisions) . 

Gotterbam might have added that the error of considering a code of ethics 
"uncontroversial", "trivial", or otherwise no more than common sense when it is not, is an 
"honorable error", one most likely to be made by those who hold themselves to high standards. 
Assuming that others think as they do, they cannot see the point of the code's requiring no more 
than they require of themselves. Those who work to a lower standard tend to make the opposite 
mistake, that is, to suppose that the code is "unrealistic" or "impractical", sets too high a 
standard", and so on. They are often surprised to discover that few of their colleagues agree with 
them about what is practical. The open discussion of what is "uncontroversial" and "impractical" 
itself helps to shape the discipline's understanding of both. We have no direct insight into much 
of practice beyond our own and perhaps that of a few people with whom we work closely. 

Below Gotterbam's response to Pamas was a related news item. The ACM had 
established an Advisory Panel on Professional Licensing in Software Engineering to assess "the 
current role of ACM as part of a joint effort with the IEEE Computer Society to oversee and 
actively participate in the development of professionalism and licensing guidelines through 
[SWECC]", to recommend "an appropriate role for ACM to take with respect to these issues", 
and to provide a "brief final report to the ACM Council by its next meeting [May 16. 1999]". 
Among the fourteen members of this advisory panel was David Pamas." While the comrmtbee 
was "free to deteraiine its course", the Council expected it to "consult with the representatives of 
the areas of ACM that have an interest in the tope [including]: SIGSOFT (David Notkin, Chair), 
the Ed Board (Peter Denning, Chair), and the ACM representatives to SWECC (Dennis Frailey 
[and the others]) ." Licensing was again causing trouble, more than GotberiDam could then guess. 
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The Gotterbam-Pamas exchange is just one example of how Gotterbam sought to 
disseminate the Code through publication. Typed of atbenpts to disseminate it through 
consulting is an exchange of emails with Ddl Conpjtei^ s legal department ("Ddl Legd"). Late 
in January, a paidegd at Ddl Legal wrote Gotteibani That email is lost, but Gotteatam's 
January 22 respjnse mates it clear that he understood Ddl to be asking permission to copy the 
Code. He informed the paidegd, "The copyright is registered to me", expressed pleasure at 
Ddl's interest, and asked wtet exactly Ddl had in mind^' A few days later, the paidegd 
expldned thd her "team is working to enhance our existing guiddines for procurement 
professionds to be appropriate for a wide group within Ddl". Her team would lite to adopt some 
of the Code's "concepts" but it "would not be a direct adoption". She then offered to send 
GotteriDam a draft if "it would mate you more comfortable". The draft of "1/26/99" ("Standaids 
of Business Ethics for PSG Professiond^ngineering Code of Conduct') airived a few days 
later (February 16). Nine pages long, it was an inp^ssive document, but showed no obvious 
borrowing from the Code. 

Gotteibam' s statement thd the Code' s copyright is "registered to me" deserves comment 
Actudly, the copyright was in the name of Miller and Rogerson as wdl as Gotterbam The 
copyright in question seems to have covered dl versions of the code, starting with "version 
1.0".^^ Copyrighting the Code was part of a strategy, dating from September 18, 1998, to avoid 
two dangers. One was that the short version of the Code might be printed without the long. The 
other danger was that the ACM or lEEE-CS might charge for the Code (as they did for other 
documents), thus (unintentionally) discouraging dissemination and use, or bury the Code by 
failing to grant permission to copy it By copyrighting the Code, Gotterbam avoided both 
dangers. He could provide free downloads of the Code at the SEERI website on condition that 
the Code not be divided and that no charge be made for copies. Neither the ACM nor lEEE-CS 
was happy with this arrangement however. They viewed the Code as a "work for hire" and 
therefore theirs, not Gotterbam' s, even though no one who had had any part in writing the code 
had been hired (except the ACM grammarian and lEEE-CS lawyer). By the middle of 1999, 
Gotterbam, ACM, and lEEE-CS had resolved the dispute. The two societies became joint 
holders of the copyright but only after agreeing that the Code should cany below the copyright 
symbol the statement "This Code may be published without permission as long as it is not 
changed in any way and it carries the copyright notice." It carries that notice to this day.^^ 

Copyrighting the Code was a smdl part of efforts to create the orgardzationd 
infrastmcture to disseminate the Code more widdy. The Software Engineering Ethics Research 
Institute (SEERI) was another (10. 2); so too was ACM's Committee on Professiond Ethics 
(COPE). But once SWECC replaced the Joint Steering Committee, it seemed obvious thd 
dissemination had to include SWECC, especidly if SWECC got the funding and stdf support it 
was asking for. Gotterbam therefore devdoped a plan for a "project' under SWECC 
corresponding to the task force he had chdred uriler the Steering Committee. Unfortunatdy, by 
this time, the Software Engineering Education Project had the acronym "SWEEF'. So, 
Gotterbam could not name the project he was planning "the Software Engineering Ethics 
Project'. Its obvious acronym, SEEP (not to mention "SWEEF'), would be too easy to confuse 
with the Education Projects SWEEP. Gotterbam dismissed "the Software Engineering Ethics 
and Professiond Practices Project' (SEEPPP or SWEEPPP) for the same reason Eventudly, he 
chose "SEPEF' (Software Erigineering Professiondism and Ethics Project), with the lucky 
suggestion of energy (TEF'). Consistency with the nomenclature of other SWECC names 
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would entail a "W" after the "S", but Gotterbam thought that consistency not worth the loss of 
the imperative sounding "SE[E]". 

Gotterbam submitted a plan to SWECC's meeting on April 15. SEPEP's plan had four 
parts: Purpose, Structure and Governance, Immediate Projects, and Initial Committee 
Membership.^^ SEPEFsptiiposesircluded publicizing the Ccxte, fostering broader acceptance of 
the Code across international boidens, updating the Code "as ^Dpropriate", and woridng with 
SWEEP to incorporate into software engineering education a knov^edge of the Code and its use 
in decision making. Among SEPEF s immediate projects were devdopng a flyer about the Code 
to be included with all ACM and lEEE-CS membenship renewals, presenting a panel on the Code 
at ^Dpropriate ACM and lEEE-CS software engineering meetings, publishing the Code in 
Communications of the ACM and Computer, working with the Education group to develop 
educational materials on the Code, and maintaining a joint ACM/IEEE-CS website on the Code. 
SEPEP was to have a three-member executive committee. Its chair was to be "a member of both 
the ACM and the Computer Society", with the other two members representing (respectively) the 
ACM and the lEEE-CS. The chair would report to SWECC annually. Though SWECC (in 
January) had required all projects to have a definite duration, SEPEP's plan included no 
termination date (though it did provide for a fiscal year beginning July 1). Nonetheless, the plan 
was approved "as presented" .^^ 

The meeting at v\Mch this h^Dpened (a teleconference) lasted only seventy-five minutes. 
SEPEP had fifteen of those minutes. Ahead of SEPEP was SWEEP s jiaa Tte chair (Tripp) 
presented it "[on] behalf of Jeny Engd and Richard LeBlanc". SWEEP had forty-five minutes. 
After SEPEP was "new bu^ness", a fifteen-minute discussion of "opportunities for promoting 
the Guide to the Software Body of Knov\dedge Project". All the "action items" for tte meeting 
concerned the Body of Knov\dedge. AU six men±)ers were "present". 

12.4 A happy but short life 

When SWECC next met (Montreal, July 13, 1999), only four men±)ers were present 
(Ardis, Carver, Frailey, and Tripp). At another all-day meeting, they ^proved "Guidelines for 
Projects and Proposals for New Projects", the minutes of the January arid April meetings, and a 
proposal to conduct annual surveys of international software engineering programs. They also 
approved the content of a "Code of Ethics poster^', though with the suggestion that "the 
presentation could be irrpoved ty consulting with a gr^±iics artist". Perii^:s most inportant, 
however, SWEBOK reported that the "Stoneman" version of the Guide to the Software Body of 
Knov\dedge (version 0.5, that is, something well short of Version 1.0) was neariy conqiete, with 
the remaining two Knov\dedge Areas expected to be conqiete ty July 23. A "few hundred" 
reviewers had volunteered, covering all the Knov\dedge Areas, bit more reviewers were being 
sought "to represent other points of view". Beside the Texas Board of Professional Engineers, 
"other groups (especially in Canada) have been taking actions about licensing software 
engineers". There was agreement that SWECC "needs to enter into formal agreement for the 
exchange of materials" with all of these groups. SWECC would meet again in person in late 
January 2000 and, if there was enough business, ty teleconference before then, in October. 

SWECC did not meet again, even ty teleconference, until March 4, 2000. But it 
nonetheless ended 1999 with a major achievement, a v\tole issue of IEEE Software 
(November/December) devoted to it, almost sixty pages of text. Tripp (along with Steve 
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McConnell) was Guest Editor (with an Introduction to the issue, pp. 13-18). David Pamas 
contributed the lead article (pp. 19-30), "Software Engineering Programs Are Not Computer 
Science Programs", a spirited and intelligent justification for training software engineers as if 
software engineering were just another kind of engineering. Pamas even set out— course by 
course— the curriculum he would prescribe for an undergraduate software engineering student. 
Immediately following Pamas was Gerald Engel's report on SWEEP, "Program Criteria for 
Software Engineering Accreditation Programs" (pp. 31-34). While SWEEP'S undergraduate 
criteria were designed to augment the computer science criteria ("CASC/CSAB"), the graduate 
criteria tracked ABET's engineering criteria. Following Engel's paper was "The Guide to the 
Software Engineering Body of Knowledge" (pp. 35-44). Three of its five authors (Piere Bourque, 
Robert Dupuis, and Alain Abran) were from the University of Quebec at Montreal. The other 
two were James Moore (MITRE Corporation) and Tripp. The Stoneman version of the Guide 
was available on the web for comment. Other versions would follow, each taking into account 
comments on the one before. The Body of Knowledge would always be a work in progress. 
Moore had an article of his own about another SWECC project, developing "An Integrated 
Collection of Software Engineering Standards" (pp. 51-57). Gotterbam followed Moore, 
explaining "How the New Software Engineering Code of Ethics Affects You" (pp. 58-64). This 
article includes two inserts: one, the short version of the Code (without the long); the other, a list 
of "Early Adopters". Among the early adopters is McConnell' s Construx Software (and the 
United Kingdom's Royal Mail). 

The remaining three pieces concem licensing. The first of these ("What Do You Mean I 
Can't Call Myself a Software Engineer?") was in the middle of the issue (pp. 45-50). Its author, 
John Speed, was at the time a member of the Texas Board of Professional Engineers (and 
himself a licensed— civil— engineer). His article is largely descriptive, explaining what the new 
Texas regulations of the term "software engineer" require. The other two pieces (and a short 
"Responds", at the end of the issue, are officially polemical (being grouped under the title "Head 
to Head"). Dennis Frailey defended licensing (pp. 66 and 68). Tom DeMarco, a principal in a 
"New York and London based consulting group", argued against. For DeMarco, the market 
provides "the most efficient and elegant certification mechanism ever envisioned" (pp. 67 and 
69). The only altemative to the market, a "Soviet-style central licensing bureaucracy", would do 
only one thing, protect "a class of senior practitioners whose skills are so irrelevant and so far out 
of date that they can't really do any highly paid job except licensing." Frailey's response to this 
free- market attack on licensing (p. 69) is to point out that DeMarco does not know what he is 
talking about. Licensing professionals is almost universal, even in countries without a "Soviet- 
style bureaucracy". And because licensing regulations allow the licensing body to impose 
conditions for keeping a license, "licensing is one of the few mechanisms that encourages and, in 
some jurisdictions, even requires continuing education." Licensing raises standards beyond what 
the market would otherwise impose. 

Licensing was still an issue likely to rouse passions, perhaps as likely to rouse passions as 
it was in 1993 when Buckley included licensing in his lEEE-CS Board of Govemors motion to 
begin establishing software engineering as a profession (2.3). Evidence of how licensing could 
still arouse passions appeared in the February 2000 issue of the Communications of the ACM. 
The ACM President, Barbara Simons, wrote a "Viewpoint" piece, "Not Now, Not like This", 
stressing that a licensing test "will [not] assure that the person who passes the test will be 
qualified to write programs that will never endanger the public." Part of the reason a test cannot 
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provide that assurance is that we "do not have building codes for programs." Indeed, we do not 
even have "a vocabulary of program design rich enough to discuss structural integrity. "^^ Simons 
had two co-authois, Fran Allen and Paula Hawthorn, both members of the ACM advisory panel 
established in March 1999 to report on licensing software engineers.^ ' 

That panel had reported to the ACM Executive Council on May 15, 1999 (on schedule).^ ^ 
The Viewpoint pece was, in effect, disseminating the four conclusions of that report— v\Mch the 
Council had erriorsed The Council had declared that the "ACM opposed" licensing software 
engineers "at this time" because it believed that licensing would be "premature" and would not 
address "problems of software quality and reliatality". The ACM was nonetheless "committed to 
solving the software quality problems", but (the Council declared) the way to do that was "by 
promoting R&D, by devdopng a core body of knov\dedge for software engineers, and by 
identifying standards of practice." While the ACM would continue to advise 'lx)ards and other 
agencies interested in licensing of software engineers", its "interaction will not inqiy ACM's 
endorsement of licensing or involve associated materials such as tests." Last, the Council 
undertook to form an "ACM SWECC Oversight Committee" to oversee "the development of the 
software engineering body of knov\dedge and ACM's participation in SWECC." This report 
seemed to favor most of what SWECC was doing. 

The first and last appendices to the May 15 report provided further insight into how 
contentious licensing remained. Appendix A, by John Speed, is the official report of the Texas 
Board of Professional Engineers (approved February A, 1999). A crucial element of the Texas 
approach was that a licensed "software engineer" had to be an engineer (strictly so called): "Not 
everyone with computer related experience is eligible to become a licensed Texas P.E. by 
applying under the software engineering discipline." The Board would decide "on a case- by-case 
basis who has been practicing engineering". This requirement was not as hard for computer 
scientists to satisfy as it might seem. The Board had a definition of "the practice of software 
engineering" that made explicit reference to "computer sciences". More likely to be 
discriminatory was the requirement that an applicant have letters of reference from "at least 9 
people, 5 of whom must be licensed engineers." 

Did computer scientists actually have anything to fear from engineers? Appendix C of the 
Report at least suggested that they did. According to that document, the Senate of the Memorial 
University of New Foundland, Memorial's academic governing board, had approved an honors 
program in the Department of Computer Science with a specialization in "software engineering". 
Upon learning of this degree, the Association of Professional Engineers and Geoscientists of 
New Foundland had joined the Canadian Council of Professional Engineers (CCPE) to sue 
Memorial over the use of the term "engineering". The case was set for hearing in the federal 
court in St. John's in September 1999.^^ The Association of Universities and Colleges of Canada 
(representing most of the degree-granting institutions in Canada) pledged to cover eighty percent 
of airy legal costs Memorial incurred What began as a sinideacadeniic decision had, because of 
the word "engineering", become an expensive federal case. 

On March 4, 2000, SWECC (again) met in Austin^ ' Northrop and Carver were absent, 
but the other four men±)ers were present, along with Gotterbam (for tte "Ethics Project"), Laurie 
Werth ("observer from Education Project"), Dupuis and Bourgue ("for SWEBOK"), and Gerald 
Engd (present for "the first pait of the meeting to report on tte progress of tte [Education 
Project]" through his representative, Laurie Werth). Tte "Summary of Resolutions" gives tte 
inp:ession that tte Ethics Project was tte central concern of this meeting. Of four resolutions, 
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three concerned ethics. SWECC (now written "SWEcc") approved a logo for the code of ethics, 
approved copyrighting the logo as a "committee asset", and approved "the proposed revised 
budget for the code of ethics project and flyer distribution".^^ Another resolution listed in the 
Summary thanted "the SWEBOK team for the quality of its work and its contribution to 
software engineering as a professiorL" Though these resolutions together suggest a meeting both 
dull and short, the minutes themselves (four pages, with one page-long ^Dpendix of "Action 
Items" and another of "Acronyms") suggest something else. 

The first inpjrtant item of the day concerned proposals in Indiana, New Mexico, and 
Missouri to license software engineers. The proposal from Missouri was "particulariy inpjrtant" 
(so inpjrtant that each SWECC men±)er received a copy) . It would treat software engineering as 
a specialty within corrpjter engineering. The proposal would be submitted to the NCEES 
(National Council of Examiners for Engineering and Surveying) in Fall 2000 as an alternative to 
the Texas proposal. There was a "general perception that the Missouri proposal would be less 
desirable than the Texas proposal" not only because it could "divide the [conpjting] community 
but also [because it placed] software engineering in a less influential and fundamentally 
inappropriate position as a subsidiary of conpjter engineering in the minds of the professional 
engineering community." After considering possible responses, SWECC took no action 
SWECC responded in the same way to the Texas Board's request to "review the definition of 
software engineering" ! ^ 

After this half-page discussion, the minutes of SWECC s March meeting offered 
Gotterbam's report on the Code of Ethics Project, a half-page report on an informal survey of 
software engineering programs, an informal report on SWEEP (Education), and a half-page 
report on SWEBOK (Body of Knov\dedge). Since July 1999, tiie Guide to SWEBOK had 
conqieted its "stoneman" phase and, despite "some relatively minor schedule slips due to 
delayed responses ty certain authors", was close to conpleting the "ironman". SWECC planned 
no further face-to-face meetings in 2000. It would, however, have at least one conference call 
with SWEEP and SWEBOK "to review progress" and another conference call (even later) to 
"discuss ^Dproval of the SWEBOK final document". 

That March meeting was SWECC s last Three montiis later Qune 30, 2000), the ACM' s 
Executive Council voted to withdraw from SWECC, in effect killing the orgardzation^* 
SWECC had survived littie more than eighteen months, less than a third as long as the terrpjrary 
Joint Steering Committee for v\Mch it was supposed to be the peraianent replacement Tte 
Executive Council that voted to withdraw from SWECC was the same one that had approved 
entry. It withdrew just before leaving office. To mate clear that it did not tate its decision 
ligMy, the Executive Council issued a sLx-page explanation ("A Summary of the ACM Position 
on Software Engineering as a Licensed Engineering Profession"), with three ^Dpendices: A) two 
pages of "Q&A" summarizing the Report; B) a ten-page "Assessment of the Software 
Engineering Body of Knov\dedge Efforts"; and C) a twenty-page report "On Licensing of 
Software Engineers Working on Safety-Critical Software".^ ^ Two of the three authors of the 
Body of Knov\dedge report should be familian David Notkin a nd M ary Shaw.^ ^ 

SWECC (according to the Summary) had "increasingly been perceived as furthering 
efforts to license software engineers." Two particular efforts stood out: "1) communications with 
the State of Texas relative to Texas' desire to develop a licensing exam for software engineers 
under the general framework for professional engineers (PE' s); and 2) the development of a first- 
draft of the body of knov\dedge (SWEBOK) that all software engineers would be expected to 
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know." It was such efforts that led the Executive Council to appoint a "blue ribbon panel of 
prominent software engineers" to investigate "the issue of software engineering and the need for 
licensing". The Council had decided in May 1999 that "it could not support licensing software 
engineers." The state of knowledge and practice in software engineering is "too immature to 
warrant licensing". Licensing would, under the circumstances, be "ineffective in providing 
assurances about software quality and reliability." In May 2000, the Council concluded as well 
that "the framework of a licensed professional engineer, originally developed for civil engineers, 
does not match the professional industrial practice of software engineering." Because SWECC 
had become "so closely identified with licensing of software engineers under a professional 
engineer model, the ACM Council decided to withdraw from SWECC." Though the ACM had 
withdrawn from SWECC, it continued to believe that "the problem of reliable and dependable 
software, especially in critical applications, is the most important problem facing the IT 
profession." ACM would continue to "work closely with [lEEE-CS] on projects to further the 
evolution of software engineering as a professional computing discipline and improve the quality 
of software and the capabilities of software engineers." 

There are, I think, two (compatible) ways to read what ACM did. One is that ACM had 
no objection to software engineering becoming a profession; the objection was to software 
engineering becoming an integral part of engineering (rather than a "professional computing 
discipline" or an "IT profession").^^ Integration into engineering would have inp^itant 
consequences for conpjter science as an academic enterprise. What consequences? Early in 
1999, the Naval Academy had announced a graduate program in software engineering within 
Corrpjter Science (and Information Systems), the first in the US.^^ Later that year, Camegie 
Mellon University had announced a similar program The CMU announcement listed a faculty of 
four, all from the School of Conpjter Science (Institute for Software Research 
International) .One of the four was Mary Shaw.^^ The graduates of such programs might well 
have trouble getting licensed as software engineers in Texas. If the Texas ^Dproach spread, 
programs lite that at the Naval Acaderr^^ and CMU might die— and conpjter science programs 
be the poorer in consequence.* ° 

The other way to read the ACM decision is as a misunderstanding. That was how Frailey 
read it Writing for himself in the Forum for Software Engineering Education (EASE), he 
"strongly disapprove[d]" of the ACM decision; it would have "detrimental long term 
ramifications to software engineering and to the ACM"; and it put "in doubt" the work of "over 
400 volunteers from about 50 countries" for "weak and often incorrect" reasons.*' Relationships 
"with tey external organizations" that had taten eight years to build had been severed with the 
loss of good will and respect for the ACM. Frailey was equally dis^pointed with how the ACM 
had reached its dedsiorL The process had been "exclusionary". Neither the Executive Council 
nor its task forces had "consider[ed] the views and insights of ACM's ^Dpointed SWEcc 
representatives. . .the people actually doing the work— even after we offa:ed to provide 
irformation and to assist in the discussions". One result was that the draft rationale contained 
"incorrect assunptions and factual enors" that, though easily corrected, "may well have 
influenced the Council' s decisiorL" For exanple, the draft report said that SWECC "focused . . on 
matters of licensing", it did not— "ask anyone v\to has attended one of our meetings". SWECC 
had not as suggested, supported licensing in ways inconsistent with ACM policy. In fact it had 
"dissuaded the Texas Board from devdopng an examination and convinced them that ACM was 
an ^Dpropriate authority to tum to for advice in this matter" While Frailey hoped that "the work 
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of the four SWEcc projects will continue under some banner" supported by the "software 
engineering community", the work would now have to go on without "the coordination and 
communication functions that SWEcc provided, the united front presented by the ACM and the 
Computer Society working together, and the influence on these activities that ACM could have 
had." The ACM had, in effect, ceded the project of establishing software engineering as a 
profession to lEEE-CS— and lEEE-CS had always looked on licensing with more favor than the 
ACM had. For Frailey, ACM's withdrawal from SWECC was a strategic blunder. 

12.5 Software Engineering Ethics Coordination after SWECC (2000-2004) 

This book's importance depends (in part at least) on the importance of the process 
studied. If writing the Software Engineering Code in particular, or establishing software 
engineering as a profession in general, is merely a failed attempt to establish a profession, the 
thinking about professions preserved here will seem less important for understanding 
professions. This book would seem likely to tell us no more about living professions than an 
autopsy of a fetus spontaneously aborted can tell us about children bom alive. We are, of course, 
not yet in position to know that software engineering has succeeded in becoming a profession. 
We need a decade or two— at least. Events between SWECC's dissolution and completion of this 
book do, however, provide some evidence that the attempt is succeeding. I can think of no better 
way to conclude this chapter than by (briefly) recounting that evidence. 

Software engineering has continued its transformation from a field of computer science 
into a field of engineering (strictly so called). Two events seem especially relevant here. On 
March 14, 2001 (after what he described as "2+ years" of silence), Gotterbam emailed a score or 
so of those involved in writing the SE Code of Ethics that (among other things) the "IEEE has 
started a Certification for Software Engineering Professional." In addition to "experience, 
education and passing a test they require adherence to the Code".'^^ When I looted at the lEEE- 
CS website in 2004, I found only a certificate program for "SofbA/aie Development 
Professional", but it did include a link to the SE Code of Ethics.* ^ The Code remains an integral 
part; of IEEE certification of software development professionals (if not exactly of sofbA^aie 
engineers), ^Dpaienfly the only lEEE-CS (or IEEE) certificate program Whether or not 
certification is essential to profession, it is clear that the certification of sofbA/are engineers is 
now treated as part; of engineering certification— and linted to the SE Code. 

Sometime in August 2001, the ACM's Task Force on Licensing of Software Engineers 
Woridng on Safety-Critical Software issued a 'Tinal Report;". The Report; opposed licensing (for 
reasons already familiar) but endorsed "codes of professional conduct" (without mention of the 
Software Engineering Code by name).** The Task Force did, however, recommend that the 
ACM review its codes of ethics from time to time. While the ACM does not seem to have taken 
this recommendation to heart, the lEEE-CS has. 

On November 7, 2002, the lEEE-CS Professional Practices Committee (Leonard Tripp, 
Chair) concluded that "the Code is stable and currently there is not sufficient evidence that it is 
in need of revision."*^ The Committee reported only two criticisms of the Code. One, apparently 
widespread, was that the Code did not "outline specific sanctions for violations". The Committee 
thought this no more than a misunderstanding: 'Those sanctions are generally contained in the 
tylaws." The Code need only, and does, "refer to potential sanctions... [in] 8.09" ("Recognize 
that personal violations of this Code are inconsistent with being a professional software 
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engineer")- The other criticism received was not at all common: "One Florida based computer 
manufacturing company's lawyer said the company could not adopt the Code because Clause 
6.06 admits the possibility of a circumstance where someone may ['in exceptional 
circumstances'] have to violate a law to protect the public." The company adopted all the other 
clauses of the code. The Committee thought the Code was right to say that the law should not 
trump the public interest. 

The report's appendix listed some evidence of the Code's success: five textbooks in 
"Software Engineering" that either reprinted the Code or posted it on the book's website; nine 
textbooks in "Computer Ethics" that made similar use; seven companies that had adopted the 
code (and several more that posted it on their website); and adoption of the (short version) of the 
Code by the Association of Information Technology Professionals.'^^ Most inp^ssive, perhaps, 
were the number of translations posted on the web, three "official" (Chinese, Italian, aid 
Spanish) and three more "unofficial" (Croatian, Hebrew, and J^Miese). An official French 
translation was underway (for French Canadians)." (A translation becomes official when 
Gotle±iain, after consultation with software engineens v\to speak both languages, concludes that 
the translation is reasonably faithful to the original.) 

On April 10, 2004, Keith Miller emailed Simon Rogeison (with copes to Gottertem and 
me) reporting that he had recently attended a worishop (in California) on software testing: "I 
was pleased to hear several speateis mention the joint ACM/IEEE code at the worishop when 
the issue of professionalism came up." Though the 'lack of enforcement mles was mentioned", it 
was also "mentioned that the code was an inpjrtant first step for the profession" The "technical 
worid" seemed to know about the code and that knov\dedge seemed to "make a difference".* ^ 

Meanwhile, even the Guide to the SofbA/are Engineering Body of Knowledge 
(SWEBOK)— ^:art from licensing, the most controversial part of the professionalization 
project— continued to develop. On September 15, 2001, Dupus, Bouique, and Abram, the three 
Canadians v\to had taten over "editing" SWEBOK, issued an interim report 'Trial Version 
0.95" (just short of Version 1) had been published in Febmary 2001 for review. In April 2001, 
the projects Industrial Advisory Board "recogrdzeld] that due process was follov\oi in the 
devdopment of the Guide (Trial Version) and endorse[d] the position that the Guide (Trial 
Version) is ready for field trials for a period of two years." In Msy 2001, the lEEE-CS Board of 
Governors accepted SWEBOK (Trial Version) "as fulfilling its development requirements" and 
also declared it ready for two years of field trials.* ^ 

A little over a year later (July 25, 2002), Bouique emailed a general call for position 
p^:ers and participation in a worishop on "inprovements to [SWEBOK] and to the Software 
Er^neering Education Body of Knov^edge (SEEK) to be held October 6, 2002 at his home 
institution, the Ecole de teclmologie suiperieure, in Montreal. The results of the workshop were, 
in turn, to be used as "irpjt to a second (to be confirmed) worishop" at the Conference on 
Software Engineering and Training (to be held in Madrid in March 2003). While SWEBOK now 
belonged entirely to lEEE-CS, SEEK was still an "ACM/IEEE Conpjter Society initiative to 
define undergraduate software engineering curriculum recommendations." On May 29, 2003, 
Bouique issued a caU for volunteers to review Version 1 .0— almost the final step for publication 
as a Technical Report by the International Organization for Standardization (ISO TR 19759). On 
February 6, 2004, the lEEE-CS Industrial Advisory Board unanimously agreed that "the 
Software Engineering Body of Knowledge project initiated in 1998 has been successfully 
conpleted; and endorse[d] the 2004 Version of the Guide to the SWEBOK and commend[ed] it 
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to the IEEE Computer Society Board of Governors for their approval." The lEEE-CS Board then 
approved the "2004 Edition of the Guide" (and authorized the Chair of the Professional Practices 
Committee to proceed with printing). ^° SWEBOK will hereafter be reviewed (and revised) lite 
any other IEEE standard 

Software engineering now has an (internationally defined) body of knov\dedge, 
accreditation guidelines (both graduate and undergraduate), and a code of ethics. It has 
procedures in place to maintain (and inpDve) the relevant documents, to teach them to the next 
generation of software engineers, and even to integrate them into current practice. Assuming 
these achievements are neither mirages nor ephemera, v\tot more does software engineering 
have to do to count as a profession (strictly so called)? 



368 



NOTES 

^ Aimual Report - 1998, Joint IEEE Conpjter Society and ACM Steering Commitbee for 

the Establishment of Software Engineering as a Profession www.acnLorg/serving/s^Rpt9811 
(3/23/2004). This is, as far as I can tell, the only annual report the Joint Committee ever issued 
(or, at least, ever piaced on the web) . The web version seems to have first ^Dpeared in November 
1998 ("9811") and was last updated on "2 March 1999", but (according to the draft SWECC 
schedule of September 29, 1998) should have been prepared in Febmary 1999. (Gottej±iam\ 
Version 5\ACMSUPPOKI\SCHEDV20). Since Frail^s name precedes Tripp's, the order of 
names is unusual. Usually, the chair^s name would be listed first While Tripp might be listed 
second sinqiy in submission to the alphabet, the more liMy explanation seems to be that the 
order recognized that Frailey did more of the work 

^ Gotteri:am\Vension 5\ACMSUPP0KI\ACMREPS (file date: 9/29/98). Ardis is now a 

professor in the Department of Corrqxiter Science and Software Engineering, Rose-Hulman 
Institute of Technology, suggesting (as marry other haogr^±iies here have as well) how porous is 
the boundary dividing software engineering's "technical community" from its "educational 
community". 

^ www.aanorg/serving/se^mi990128 (4/11/2004). By January 1999, Tripp had replaced 

Carver as lEEE-CS President The people are, it seems, much more stable than v\tot they 
"represent". 

* Gotteri:am\Vension 5\ACMSUPPORT\CHARV22 (file date: 9/29/98). The docunMit 

itself indicates that it is as "^proved on 19 October 1998" by the ACM, suggesting that it might 
be more recent But I doubt it The document also claims to be as ^proved by the lEEE-CS "XX 
November 1998". The final document (available at www.acmorg/serving/s^Charter, 4^11/2004) 
differs from it in a number of (minor) ways. My guess is that on September 29, Frailey and 
Tripp knew the exact date of the ACM Executive Council meeting (only three weeks away) but 
not that of the lEEE-CS Board (almost two months off). They had merely "penciled in" the 
future. What we have here is very much a draft 

^ Here is one place v\tere the final Charter differs from the one in Gotteibam' s files. The 

language of GotteriDam' s draft was "an intended duration". 

^ SWECC's charter is also interesting for v\tot it has to say about resources. The two 

societies agree to provide funding for SWECC, dividing expenses evenly, except that lEEE-CS 
is to "provide a secretariat service for SWECC". www.acmorg/serving/s^Charter (4^11/2004). 
Another draft document of September 28, 1998 is a budget for 'TY 1999 and 2000", calling for a 
total of $12,600 for the first year and $25,000 for the second GotteatamWersion 5\ 
ACMSUPP0RT\BUDGET2. There is no budget on line. 

' "Software Engineering Professionalism and Ethics Project (SEPEP), April 1999". 

www.acmorg/serving/se/Sepec (3/23/2004). 

^ GotteriDam/History of SE code^ History of proj . 
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www.acnLOig/service/se/Histoiy (2/23/2004). 

^° Conpare the "Rationale" for SWECC offered to ACM and lEEE-CS. GotteibamWeision 
5\ACMSUPPORT\Repoit 

' ' ABET has long included "technology" programs as well as engineering programs in its 
accreditation work and, from the ACM's perspective, integrating CSAB with ABET may have 
seemed no more than a more efficient way to do v\tot it had been doing all along. 

12 www.acm.oig/servic^s^Histoiy (2/23/2004). 

' ^ www.acnioig/serving/s^min990128 (4/1 1/2004) . 

'* "Perforaiance nornis" seem to be another way to talk about "standards of professional 
practice". 

'^ David LoigePamas, "On Code Reuse", Software Engineering Notes 24 (May 1999): 4 

'^ David Loige Pamas, "SDL A Violation of Professional Responsitality", Abacus 4 ( 

1987): 46-52. Reprinted in (among other places): Deborah G. Johnson, editor, Ethical Issues in 
Engineering (Prentice Hall: Englewood Cliffs, New Jersey, 1991). Quote in Johnson, p. 15. 

" Don Gotbedem, Keith Miller, and Simon Rogerson, "On Code Reuse: a Response", 

Software Engineering Notes 24 (May 1999): 4-6. 

' ^ GotteriDam, Miller, and Rogerson, p. 5. 

" The others were: Fran Allen (co-chair), Bany Boehm, Fred Brooks, Jim Browne, Dave 
Farber, Sue Graham, Jim Gray, Paula Hawthorn (co-chair). Ken Kennedy, Nancy Leveson, Dave 
Negal, Peter Neumann, and Bill Wulf. Software Engineering Notes 24 (May 1999): 6. This is a 
committee of notables, but of academic notables [explain]. 

^ ° For other exanqies of GotteriDam' s printed dissemination of the Code in 1999, see: Don 
Gotterism, 'Two Approaches to Conqxiter Ethics", SIGCSE Bulletin 31 (June 1999): 11-12; 
Don Gotterbam, Keith Miller, and Simon Rogerson, "Software Engineering Code of Ethics 
Approved", Communications of the ACM 42 (October 1999): 102-107; and Don Gotterbam, 
Keith Miller, and Simon Rogerson, "Computer Society and ACM Approves Software 
Engineering Code of Ethics", Computer 32 (October 1999):84-88. 

^' GotterbamWersion 4 IEEE Vote\SEPEC after 5.1\Dell\Sharil. 

^^ GotterbamWersion 4 IEEE Vote\SEPEC after 5.1\Copyrigh. [sic] 

^ ^ Gotterbam once remarted in conversation that he now regrets failing to mate notification 
a condition of use. With notification, he would have a better idea of how widely used the code is. 
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24 www.acirLOig/serving/se/Sepec (3/23/2004). Another version of this plan, 
indistinguishalie except for its title date of "December, 1999", is on the lEEE-CS website: 
www.con^xiter.oig/tafc/SVVEC9912 (4/11/2004). 

2^ www.acnioig/serving/se/n]in990414 (4/1 1/2004) . SWEEP s plan, adopted the same day, 
has a fifteen month schedule (but no "temination date"), www.acmoig/serving/se/sweep 
(4/11/2004). 

^^ Ba±ai:a Simons, Fran Allen, and Paula Hawthorn, 'TSbt Now, Not Lite This", 

Communications of the ACM (February 2000): 29-30. 

^ ' The inclusion of Hawthorn among the co-authors provided some balance. While Allen, 
along with ten other men±)ens of the panel, had opposed licensing. Hawthorn, along with two 
others (Browne and Pamas), had favored it 

^ ^ "ACM Panel on Professional Licensing in Software Engineering Report to Council (May 
15, 1999)". www.acmorg/serving/sepolicy/repoit (4/22/2004). 

^^ For more details, Karen Hawthorne, "Engineering program accreditation to proceed at 
Memorial University", Engineering Dimensions (May/June 1999): 10. 

^ ° In addition, CCPE halted the process of accrediting Memorial' s engineering programs— 
until the Supreme Court of New Foundland told CCPE it had gone too far. It could not hold up 
the accreditation of engineering programs as a way to pressure Memorial to reverse its decision 
concerning a conpjter science program 

^' This meeting was held in corgunction with the 13tii annual Conference on Software 

Engineering Education and Training, March 6-8, 2000, also in Austin 

^^ www.computer.org/tab/prBsentymin20000304 (4/18/2004). 

^^ The Texas definition was quite detailed, but (by allowing for "computer sciences") did 
not obviously exclude most ACM members likely to be interested in licensing: "The practice of 
software engineering will mean a service or creative work such as analysis, design, or 
implementation of software systems, the adequate performance of which requires appropriate 
education, training or experience. Such education, training or experience shall include an 
acceptable combination of: computer sciences such as computer organization, algorithm analysis 
and design, data structures, concepts of programming languages, operating systems, and 
computer architecture; software design and architecture; discrete mathematics; embedded and 
real-time systems; or other engineering education. Such creative work will demonstrate the 
application of mathematical, engineering, physical or computer sciences to activities such as 
real-time and embedded systems; information or financial systems, user interfaces, and 
networks." www.acm.org/serving/se_policy/report (4/22/2004). 
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^^ ACM membens wiae not notified of the decision until a "Summary" was published on the 
ACM website (www.acmoig/serving/sepolicy/selepmain) on July 7, 2000 (and made final on 
July 17). DonBagert, "ACM Withdraws from SWEcc", EASE {Forum for Advancing Software 
engineering Education) July 2000. www.cs.ttu.edu/fase/vl0n07 (4/18/2004), p.U. 

^^ www.acmoig/serving/se_policy/selep_main (April 22, 2004). The authors of the report 
on licensing were: John Knight, Nancy Leveson, Michael DeWalt, Lyrm Elliot, Cem Kaner, and 
Helen Nissenbaum The final version of this report (dated August 2001) seems to have been 
published (or, at least, 'last modified") on October 12, 2001, bearing the copyright "(g)2001 John 
Knight and Nancy Leveson, all rights reserved". 

^^ The third author, Michael Goriick, had worted at Aerospace Corporation for more than 
twenty years on such projects as "wearable conpjting, grid conqxrting, peer-to-peer 
infrastructure, large-scale data mining for stmctural genomics, internet ^Dpliances, and wireless 
devices. Sunsetusc.edu/gsaw/lios/goriick (April 23, 2004). 

" The ACM did not mate clear in v\tot sense software engineering either is or might be a 
"profession". Insofar as software engineering had a code of ethics of its own (and seemed to be 
trying to live by it), it was by this point a profession separate from engineering— v\tether or not 
it was a "conpjting discipline" or an "IT profession". 
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EASE, July 1999. www.cs.ttu.edu/fase^79n07 (4/18/2004). 



39 FASE, February 2000. www.cs.ttu.edu/fase/vl0n02 (4/18/2004). This "Institute" is not to 
be confused with the Software Engineering Institute. According to its website 
(http://www.isri.cs.cmu.edu), "[i]n addition to participating in the School of Computer Science's 
top-rated undergraduate program in Computer Science, ISRI offers: A PhD Program in Software 
Engineering, A PhD Program in Computation, Organizations and Societ]/, Professional Masters 
programs in Software Engineering and Electronic Commerce Distance education in Software 
Engineering with and without academic credit" Italics in original. 

* ° Indeed, the problem for corrpiter science might be even worse in some states, those that 
require ariyone teaching "engineering design" to be a licensed engineer. 

* ' EASE, July 15, 2000. www.cs.ttu.edu/fase^^l0n07 (4/23/2004), p. 14. 
Email (Gotteri:amto Davis), March 14, 2001. 
http://www.computerorg/certification/cert_ for_you.htm (August 6, 2004). 
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** John Knight et at "On Licensing of Software Engineering as a Profession: Final Report 
of an ACM Task Force, August 2001", http://www.acm.org/serving/se.policy.html (February 8, 
2003). While the report also endorsed curriculum improvement as a way to improve software, it 
expressed considerable doubt that the Software Engineering Body of Knowledge (SWEBOK) 
would become a useful document any time soon. Apparently, SWEBOK was still linked in many 
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ACM minds with licensing. See, for example, J. Barrie Thompson, "Any Real Progress, or Is it 
Just Politics and Turf Wars?" FASE (September 15, 2001), p. 18. www.cs.ttu.edu/fase/vlln09 
(5/21/2004), p. 14 : "The real difficulties are obviously associated with the Texas model for 
licensing software engineers and it is really unfortunate that the SWEBOK project is viewed by 
many (perhaps wrongly) as being inextricably linked to the Texas actions." 

^^ "Professional Practice Commitbee Meeting 1 1/7/2002". For explanation of this report, see 
Gotbeibam's email to me (April 28, 2004): "IEEE revises technical documents— the IEEE 
professional practices commitbee asted me to report to them in 2002 on the status of the Code, I 
have attached draft of that report". The report is an attachment to this April 28 email. The 
Commitbee can only be fourd on the lEEE-CS website at http://www.conpjber.org/csinfo/ 
standingcoms.pdf (Sepben±ier 20, 2004). The Commitbee, though ^parently predating SWECC, 
seems to be acting as its successor (within lEEE-CS, of course). Its agerida for November 7 
certainly resembled SWECC s. There is, for exanple 'liaison" with the "SWE Curriculum 
project", the "SWEBOK Guide (Ironman Version)", and "SWE licensure activities" (among 
otters). Tte Committee had ten members (beside Tripp). One of them was Dennis Frailey. FW 
PPC #12 7 NOV 2002. 

*^ Tte report lists tte following website as its source for AITP adoption: 
http//www.aitp.org/downloads/AITPAdoptstte SoftwareCode.doc. When I chected that site on 
August 11, 2004, it contained no reference to tte SE Code. 

^^ On April 28, 2004 (email to Davis), GotteriDam reported a German and an Aratac 
translations "in progress". AU "official" translations are posted on tte website of Gottertem's 
Software Engineering Ethics Research Institute: htlp//seeri.etsaedu/Codes/defaultshtm (August 
15, 2004). All seven of tte translations mentioned in tte 2002 report are there. 

*^ On July 18, 2004 (email to Davis), Gottertem announced in a postscript: 'Did I tell you 
that tte Australian Conpjter Society and tte Australian Institute of Engineers have adopted tte 
Code[?] That is especially interesting because it gives it a 'semi'-legal status. Following it is part 
of your professioriial obligatiorL I have been having discussions with tte New Zealand Society 
and they are liMy to adopt in a few months." 

*" Forum for Advancing Software Engineering Education 11 (Sepben±ier 15, 2001), p. 3. 
http//www.cs.ttu.edu/fase^^l ln09.txt By then SWEBOK had been examined by almost "500 
reviewers in 40 countries" (during one of three reviews). Bourque email. May 29, 2003. 

^ ° http//www.swebok.org/teme.html (August 1 1, 2004) . 
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Epilogue: Lessons for Code Writers, Theorists, and Researchers^ 

"History is philosophy from examples." 
— Dionysius of Halicamassus, Ars Rhetorica, xi. 2 

13.1 What we can leam from this history 

It is often said that "those who do not leam from history are doomed to repeat it." Why 
"doomed"? If history consists of noble achievements, of getting things right, we would be happy 
to repeat it. There would be no "doomed" about it. What ignorance of history dooms us to repeat 
is, it seems, the past's mistakes. History (not the past itself but our rendition of it) consists 
largely of mistakes from which we are supposed to take the lesson, "Don't do that!" Yet, 
according to one of the great students of history, "What experience and history teach is this— that 
people and governments never have learned anything from history, or acted on principles 
deduced from it."^ The lesson of history is that we do not leam its lessons; we are all doomed 
Though sweepng enough to be widely quoted, this lesson seems too bleak to be true. 

I do not deriy that history, including this history, consists, in large part, of mistates. How 
could it be otherwise? Humans mate a great marry mistates and find those of others particularly 
interesting. That is v\^ Hegel thought the history of a h^Dpy people (one for vAiom. things 
generally go well) a "blank"? Yet, it is success, not failure, that we want for our own projects; 
the successful, not the failed, that we admire and want to copy. The past, evenv\tenitish^Dpy, 
seems to tell us something about the present, about how to shape the future, something we want 
to Imow becaiise it could be usefid, tdling us v\tot to do and v\to not to do. And, in sorne fields, 
such as engineering, we seem to have evidence that the past has been useful in just this way. 
Keeping good records is central to engineering. Engineers study their mistates, develop routines 
designed to avoid making those mistates again, teep to those routines as long as they seem to 
work, and in fact are much more liMy to mate new mistates than to repeat old ones. 
Engineering certainly seems to testify to our atality to leam from history— or, at least, from the 
past* 

Even so, learning from history is not without paradox. Maix once observed that vMle 
great events may occur more than once, the first time is tragedy while the second is farce.^ The 
difference betv\mi tragedy and farce is dramatic enough to suggest that Marx doubted that 
history could repeat itself. The second instance always differs in at least one way from the first 
While the first is novel; the second is not The existence of a predecessor is part of what converts 
the "tragedy" (the inevitatality) of the first into the "farce" (the unnecessary and therefore 
laughable imitation) of the second Yet, if history does not repeat itself, how is it possible to 
leam ariything usefiil from it? Why is it that an engineer who mates an old (and inportant) 
mistate is generally out of a job (fired for "inconpetence") v\ten a new mistate would have 
been excused as "just one of those things"? What can we tate from one circumstance and ^Dply 
in circumstances that always differ in marry ways? 

For practical people, the answer is obvious: we leam from history just as we leam both 
from today' s experience and even from the imagined experience of f iction. We sinply "see" the 
similarities in different circumstances, ac^usttng our conduct in new circumstances to tate 
account of v\tot is old in them What is not obvious is how we do that Indeed, explaining how 
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such "seeing" is possible is the domain of both traditional epistemology and contemporary 
philosophy of science— and questions belonging to any domain of philosophy are questions 
having at least two plausible but inconsistent answers (and, often, several more than two). I can, 
therefore, make only a modest claim for the "lessons" I will draw from this history. 

The lessons of history seem to be no more than rules of thumb, mere presumptive 
approximations of what will stand up to experience we have not yet had. If following a certain 
rule of thumb seems unlikely to turn out too badly, we follow it. If following it ends up badly 
more than rarely, we develop "doubts" but stick to the rule until we find a better one (since even 
a rather unreliable rule is better than none). There is no rigor in either the presumption or the 
approximation. We cannot rerun events to determine what actually caused what; we simply guess 
and go on. While we can test our guesses against experience, our experience seldom, if ever, 
speaks decisively. Today's apparent success (or failure) may turn into its opposite tomorrow. 
Though every history has a last page, the past does not— or, at least, by the time it does, it will 
not matter. We are always like the man who, jumping from a tall building and being asked part 
way down, "How goes it?" responds, "Very well— so far." When should we declare the 
"experiment" over? The end of the world is too late— and too hypothetical. 

The "lessons of history" are interpretations of events, interpretations that (as T.S. Elliot 
put it) "a moment may reverse." These lessons cannot be about the future. The future will 
resemble the past only roughly. (Almost every day has its surprises, some nasty.) The lessons of 
history must be about something we can know— without knowing the future— possibilities, what 
can happen (rather than will happen). Whatever else history can show, it certainly can show what 
is possible, possible not simply in the abstract logical sense that unicorns are possible but in the 
practical sense in which (as we have learned) even an "unsinkable ship" can sink (and that 
therefore even an "unsinkable ship" should have enough lifeboats for all passengers and crew). 
Lessons about what is possible in practice are valuable as guides because they wake us to 
considerations that might doom us if we miss them. No substitute for judgment, these lessons 
merely aid it, much as a "check list" does. The lessons of history alert us to ways in which we 
might improve our deliberations. They do not prophesy. Even when stated as imperatives, the 
lessons of history should be treated as advice: "Think about this." That, anyhow, is the spirit in 
which I offer this Epilogue's "lessons". They neatly divide into three categories: lessons for 
those writing a code of professional ethics (13.2); lessons for theory (13.3); and lessons for those 
interested in undertaking research much like this (13.4). 

13.2 Some Lessons for Code Writers 

The events recounted in the preceding chapters suggest at least the following lessons: 
13.2.01. Keep the writing of a code of etiiics separate from any discussion of 
licensing (or other controversial projects). Though some models of profession treat licensing 
as a defining feature, in practice licensing raises many administrative questions merely having a 
code of ethics does not. Hence, keeping the question of having a code of ethics separate from 
questions of licensing, even from the question of whether following the code should itself be a 
condition of keeping a license, should reduce the number of obstacles in the way of adopting the 
code. The chances of a would-be profession adopting a code of ethics is, at any time, sufficiently 
low that not adding to the obstacles seems prudent. (Had the Joint Steering Committee taken 
even the limited interest in licensing that SWECC did, it might have had as short a life as 
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SWECC, and the Code might have aborted.) There is also a theoretical reason to keep writing a 
code separate from licensing. The claim that licensing is a defining feature of profession is itself 
controversial.^ That controvensy may have practical inplications. At least some practitioners 
tate theories serioiMy emugh to vote against a co(te that seems to them to \dolate thdr theoiy^ 
code destined for use in licensing may have to allow some conduct a code designed for 
individual guidance need not Much of the difference between engineering's two m^or codes 
seems to have this origin The Code of Ethics of the National Society of Professional Engineers 
was designed to be used ty state boards of licensure; tiie ABET code was not 

13.2.02. Keep the drafting committee small. Preparing a first draft of a code is not an 
activity made lighter "by many hands". It is more like the soup that "too many cooks" spoil. That 
is why the IEEE's Standard writing procedure, followed in Melford's Guide 4.1.4, advises: 

The WG Chairperson should then identify an individual to author an initial draft. The 
author should be permitted to prepare the draft with or without additional input or 
assistance from any other WG members, at his or her discretion.' 

Every code of ethics needs v\tot Mechler called "a Thomas Jefferson" to do a first draft (5.2). 
The drafter has two problems that need to be solved before large numbers of people become 
irwolved in the drafting. One is content determining v\tot should be in the first draft The other 
is criticism Even a "first draft" should go through several stages before being declared a fit 
sutgect for public discussion The entire committee concerned with drafting the code should not 
exceed ten its core should be no more than three or four. The actual drafting should be one 
person's work (though there might for exanple, be one drafter at an eariy stage and another 
later); the eariy criticism, the work of half dozen or so. 

13.2.03. Keep preparation for the first draft simple. The problem of content can be 
solved in several ways. The Gotterbam- Mechler method is one. Have a small working group 
read as many other codes of ethics are possible, looking for provisions its members like. Make a 
list of provisions anyone likes. Circulate the list asking whether any more provisions should be 
added (and what those provisions should be). Continue expanding the list until it seems relatively 
complete. (Provisions to which anyone strongly objects should be put to one side to be revisited 
once there is a rough draft.) When the list seems complete, give it to the drafter. 

Another way to generate such a list is to hold sessions at the appropriate professional 
meetings. A member of the drafting committee presents some "ethics cases" to resolve— and 
invites the audience to suggest others that are "different". The audience then seeks to resolve as 
many of the cases as time allows. Part of resolving each ethics case is stating a "value" or "rule" 
supporting the resolution. Any value ("candor") or rule ("Don't mislead") the audience finds at 
all persuasive goes on a list from which the draft will derive content. The drafting begins when 
the list seems to have become stable (or when the meetings no longer surprise those who lead 
tiiem).^ 

There are other ways to develop the initial content of a code. The exact way does not 
much matter because the exact content put into the first draft does not much matter. Mistakes of 
content can be fixed later. All that is important about the initial content of the code is that it be, 
by and large, appropriate to tiie profession in question and tiiat there be enough of it to get tiie 
drafter started. 
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The history of the Software Engineering Code nonetheless shows that not all procedures 
are equal. Indeed, that history definitely recommends against two strategies. One is "divide and 
conquer", breaking work on the code into parts; the other is choosing the architecture before 
drafting begins, the "Scope" statement.(4.3) These two strategies share a common mistake. They 
assume that we know more about the future code than we can know without knowing what it will 
say. Dividing the code into parts assumes we know what the parts of the code will be. A 
comparison of SEEPP's original division of working groups and the Code's final list of eight 
Principles provides clear evidence of how hard it is to know even the major points to cover. The 
main problem with choosing the architecture before the content is not that some structures (say, a 
short code) may rule out a good deal of content (although it certainly may). The problem is that 
the architecture of a code should serve its content. Debating the architecture without knowing the 
content is likely to be uninvitingly abstract, the domain of a few monomaniacs. Gotterbam's 
working group was saved from that abstract debate only because no one cared enough about the 
abstract architecture to respond to his call for discussion of the Scope. Mechler's SEEPP/E was 
saved in exactly the same accidental way. 

13.2.04. Get a draft as soon as possible bitdoiKtdrciiatBitloansjm^iontativebody 
arinS\iducd wM ffiedzft is "fined". Like all writing, code writing occurs largely on paper. 
Without a document, it is hard to do anything useful. To get a good draft may take years, but 
getting a "working draft" (that is, a draft good enough to work with) need not take more than a 
few months. Any committee (task force or working group) assigned to write a code of ethics 
should try to get a working draft as soon as possible. But, having got one, they should be slow to 
share it with the body that appointed them— or anyone else in a position of importance. We like 
to show off our accomplishments, and even a first draft feels like an accomplishment. We must 
therefore take care not to do "what comes naturally". Anderson's experience with the ACM 
Executive Council (3.3) and Mechler's experience with the Joint Steering Committee (5.6-5.7) 
tell the same story. Governing bodies are likely to have opinions about what a code of ethics 
should contain and to express them if asked. Having expressed those opinions, such a body is 
likely to find it hard to take them back. And having heard those opinions, the drafting committee 
is likely to want to write for the governing body rather than for the membership as a whole. That 
would not be such a bad thing if the drafting committee actually knew how the governing body 
would vote on particular provisions (or on the code as a whole). Generally, though, that 
knowledge is unavailable. In its place are the statements of a few outspoken members of the 
governing body or, at best, the body's first reaction, something not necessarily even close to how 
it would vote if it were voting on a final document. 

13.2.05. Have a well-defined procedure in place for turning the first draft into a 
final draft. Those setting up a committee to draft a code should provide such a procedure. When 
Barbacci advised Gotterbam and Melford to follow the IEEE Standards procedure, he did just 
that. However complex that process was, it turned out to be less complex than the one SEEPP 
fell into when it proceeded ad hoc. Because codes are never really finished, an "open ended 
process" must go on until arbitrarily cut off. Sometimes, especially in small groups (such as 
Mechler's), participants may understand the arbitrariness as necessary, especially if exercised 
late enough in the process that participants have begun to tire. In larger groups, however, there 
are likely to be some who resent the arbitrariness, becoming enemies of the code because they 
object to the process. So, if there is no set procedure in place when the drafting committee is 
appointed, one of the committee's first acts should be to define one, a procedure to follow from 
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first draft to final adoption. The drafting committee should make the rules governing its 
procedure public as early as possible to avoid unnecessary misunderstandings. It should try to get 
official approval of the procedure but not treat silence as disapproval (or even failure to 
approve). And it should stick to the procedure (so long as not disapproved)— unless it discovers 
it has made some serious mistake. Most of the remaining "lessons" concern this public 
procedure. 

13.2.06. Make the procedure as open as possible once there is a first draft. The 
openness of the procedure has two (related) functions. First it protects the code from the 
influence of prominent but eccentric individuals who would otherwise "represent" those less 
prominent. We have seen how often prominent individuals may misjudge the opinions of those 
they try to speak for. Second, the openness protects the drafting committee both from that error 
and the error of forgetting about practical considerations altogether (always a tendency in so 
high-minded an enterprise as drafting a code of ethics). Recall how many "aspirational" 
provisions entered Version 2 or Version 3 of the Code only to be ejected by Version 4. The 
IEEE's system of voting with comments is one way to open procedure, especially in a large 
organization or collection of organizations. Anderson's presenting of drafts at sessions of 
professional meetings, taking comments, and trying to revise in response before the next 
professional meeting, is another (3.3). Gotterbam's survey is a third (8.1-8.2). Even Mark 
Kanko's survey of his students provided much useful information of this sort (6.7). What all 
good open procedures share is the drawing in of many people who, until then, had no connection 
with the drafting but are a fair sample of much of the code's actual audience. 

The IEEE Standards procedure has at least three advantages over the others (above) 
worth noting (even though it was designed for technical standards, not a code of ethics). First, it 
assures a mix of new people in a way the others cannot. Anyone opposed to the code is likely to 
object that the code ignores such-and-such a constituency. The IEEE procedure (more or less) 
automatically answers that charge before it is made (at least for any substantial constituency). 
The procedure incorporates that constituency into the voting. Second, the IEEE procedure, 
though selective, is likely to bring in more participants than ostensibly more open procedures. 
The number of people participating in any way in the writing of a code of ethics is likely to be 
small. Gotterbam's original world-wide call for participants brought in less than sixty names. His 
survey, published in magazines with a combined subscription of perhaps a hundred thousand, 
brought in just over sixty ballots. The IEEE procedures brought in an initial vote of just under a 
hundred fifty. Apparently, people are more likely to participate in response to a personal 
invitation than to a general call. Third, the IEEE procedure sets a limit on how many people need 
to be brought into the process (enough to have a good representation of each important group). 
The limit avoids the charge that too few people were involved, an important charge to avoid 
because the process from drafting to final approval seems unlikely to involve numbers large 
enough to refute the charge directly. 

13.2.07. Email is no substitute for in-person meetings. Email seems to have been an 
important new tool for helping to open the process of writing the Code to people who might not 
otherwise have participated. They seem to have participated by email when they might not have 
participated by phone, fax, or conventional mail— in part, it seems, because email is so much 
easier to use. Email is, however, much more like phone or fax than like a meeting in person. 
Much of the work of writing the Code was accomplished through ordinary meetings of two to six 
people. This is striking given the original commitment to do as much of the work by email as 
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possible. Also striking is the importance software engineers themselves assigned to face-to-face 
meetings; even meeting by conference call was plainly "second best". This is striking because 
software engineers are just the people we might expect to be unduly partial to email (and all the 
other new technologies). 

13.2.08. Plan on a slow process from first draft to final adoption. There are at least 
four reasons for preferring a slow process to a fast one. First rushing tends to increase the 
number of errors, not only small errors (such as "typos" or unnecessary variety in language) but 
even big errors like dropping provisions that would otherwise have been adopted or including 
provisions with relatively little support. Second, a slow process tends to build support. People 
have time to consider arguments, to learn how many others agree with them, and even to gather 
information. A slow process allows for more debate, more revision, and even more "politicking". 
No one can (justifiably) complain that the code was "rushed through". Third, a code of ethics 
adopted too quickly is, all else equal, more vulnerable to repeal than one that has had to win 
adoption more slowly. Fourth, planning for a slow process forecloses another sort of complaint. 
So long as the work is "on schedule" , there are likely to be few complaints about lack of 
progress even if the committee takes half a decade to write a code. There will, however, be 
complaints much sooner than that, perhaps even within a year, if there is no schedule, just as 
there would be if work were plainly "behind schedule". 

13.2.09. Find ways to test the code by making people use it ("user testing"). This 
lesson, though related to the two preceding ones, makes a different point. The problem that 
testing the code is to solve is not that of getting the right content or wide participation, but of 
getting a code that is "user friendly" (one that suits those who are to use it). Claims that such- 
and-such is the "right way" to write a code are many. Some people claim that codes of ethics 
should be short, or they will not be used; others, that they must be long or they will not say much 
of use. Some claim that a code should include principles of interpretation or it will be 
misinterpreted; others that the interpretive principles will not be used and are therefore a waste of 
space. And so on. As far as I can tell, none of these claims about how to make professional codes 
user friendly rests on much more than anecdote or personal preference. Holding sessions at 
meetings at which members of the audience are given a copy of the code, asked to use it to 
resolve some cases, and then asked to comment on the ease of use, is one way to test a code. 
Comparing those responses with responses for a code with the same content but a different 
format would provide comparative evidence. Another way to do this, less expensive in time, is to 
use students in the appropriate professional program as the research subjects. Mark Kanko's 
students seem to have responded to the software engineering code much as did mature 
practitioners (6.7). If that is generally true, then professional students could be a convenient 
stand-in for practitioners. 

What is actually needed is a systematic study of codes the results of which would be 
available in print to anyone about to write a professional code. Until we have such a study (or, 
better, several of them), the least anyone writing a code should do is some testing to identify 
serious impediments to using the code. Right now, the choice of code format seems to be one of 
those domains of expertise in which "nobody knows much" and "the louder they talk, the less 
they know". Anyone who claims to know anything about code format should immediately be 
asked for the evidence.^ 

13.2.10. Work for consensus (rather than simple majority). Ideally, a code of ethics 
should consist of those standards everyone in the group, at her rational best, wants everyone else 
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in the group to follow even if that means having to follow them to. Because people are seldom at 
their rational best it is impractical to demand that everyone actually agree to the code. Y et a 
bare majority, though practical in the sense of being relatively easy to get is not a very strong 
indication of what members of the group at their rational best would agree to. Two-thirds, three- 
fours, or consensus (no strong objections) is a much better indicator. These higher levels of 
support, though harder to get than a bare majority, are practical in the sense of being useful (as 
well as possible). A code that survived by one vote today may die tomorrow with the change of a 
single one vote. A code that had three-fourths of the votes today is unlikely to face strong 
opposition tomorrow. 

There are many ways to build consensus. The IEEE Standards process is just one. But it 
is a clever one, since it is designed to move from decisive support (two-thirds) to near unanimity 
in a way those participating are likely to respect. It commits people to reasons as well as votes; 
then responds to the reasons in ways likely to get the negatives to change their vote (not only as a 
technical requirement but with real conviction). Anyone designing a procedure for adopting a 
code should try for similar effects. The governing body should not find adopting the code a hard 
decision. The process by which the code reaches the governing body should vouch both for its 
workmanship and for its support among the general membership. As the IEEE's 1987 code 
showed, the life of a code of ethics lacking widespread support can be quite short. The process 
should build support. 

13.2.11. Get a writer to serve as the drafter or at least to work over the draft both at 
an early stage and agam near the end. By a "writer" I do not mean a grammarian, lawyer, or 
poet but (merely) someone whose other work shows that she can write a clear sentence, order 
sentences so that one seems to follow from another, and produce large works that are a pleasure 
to read and easy to outline. Steve Unger is a good example of a writer in this sense; Keith Miller 
may be another. The writer need not have much to say about the substance of the code. Indeed, it 
may be an advantage to know no more than enough to ask, "What does this mean?" when a 
sentence is in fact unclear. Version 5.2, though improved in many ways since Version 1, clearly 
suffers from not having a writer work it over before adoption. A writer would, for example, 
probably have revised Principle 1 ("act consistently with the public interest") so that it is parallel 
to Principle 2 ("act in a manner that is... consistent with the public interest"). 

13.2.12. Keep objectives modest. I have already noted how small a group is likely to 
constitute the core of the writing process, and how few can be expected to take part even in a 
process of ratification as open as that Gotterbam presided over. Hoping to involve a few hundred 
in the process of drafting, revising, and adopting a code of ethics may be reasonable; hoping to 
involve thousands probably is not (or Gotterbam surely would have recruited many more 
participants than he did). Much the same is true about other aspects of writing the code. The 
objective of writing a code is to get a code that is "good enough", that is, a code (almost) 
everyone can live with, learn from, and have ideas about how to revise. Over all, it is reasonable 
to try to make small improvements on the procedures by which earlier codes were written, on the 
code's form, and on its content To try for "perfection" in procedure, form, or content is not 
Anyone who demands perfection will get nothing. 

13.2.13. Do not list "authors", "contributors", or the like in the code itself. The 
Software Engineering Code followed the ACM's in listing names of individuals at its end, 
indicating that they were members of the body that developed the code.^° In both cases, the list 
became a permanent part of the code. This was, I think, an innovatiorL I know of no other code 
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that has such a list. Credit for helping to prepare a code is usually given in an accompanying 
report or in the minutes of the appropriate meeting. The names are soon forgotten. To give credit 
in the code itself may seem a good way to repay the contributions of volunteers who receive no 
other reward for their work (except the satisfaction of having done it). But there are at least two 
objections to the practice. One is that including a list of names in the document adds to the cost 
of reproducing the document and to what one has to get through to use it without adding 
anything to its utility. A code of ethics is not an academic publication but a tool to be used in 
making difficult decisions. It should be designed accordingly. The second objection is that the 
list is likely to be misleading. Those listed will not all be listed for the same reason; their 
contributions may be quite different— and, indeed, some may have made no contribution at all, 
except signing up for the task force. When I first asked Gotterbam about his list I described it as 
the list of "signers". He objected: 

At each go round of the Code, different people had differences of opinion. We all worked 
on a document and I don't think anyone, including myself[,] is completely satisfied[,] so I 
guess it is wrong to say the people on the list "signed off" on the Code." 

Gotbedem also did not want me to describe the list as consisting of those v\to "contributed" to 
the Code because there "are at least two names on the list that never contributed anything." Why 
were those names still on the list? Gotieibam could not he thought singly remove them once te 
had put them on— even if he put the narne on only becaiise the person narned had once signed up 
for the task force: 

There is no way to remove a name from a volunteer task force, so I subtly sent out a 
message asking people to say how the[y] wanted [their] name to appear on the task force 
list Yes[, they] did send a pefened form for their names. So the [name] ^Dpeared on all 
of the publications as men±)ers of the task force. Notice the word "active" or 
"participating" does not ^Dpear in front of the word "member" on the task force list' ^ 

GotteriDam may not have been able to avoid the pettifogging distinction between "participating" 
and "non-participating" members of the task force. But he could have avoided having that 
problem become a pennanent attribute of the Code. He need only have followed standard 
practice, omitting all names of individuals from the Code itself. 

13.2.14. Never suppose that there are experts on what a code should say. Over the six 
years during which the Software Engineering Code developed, a fair number of people, 
important and not so important made claims about what a code of ethics should or (more often) 
should not say. Many of these claims were, at one time or another, significant impediments to 
writing the Code. In retrospect most seem pompous, theory-driven prejudices, with no basis in 
the common sense of software engineers or in any statistical study of what codes of professional 
ethics actually contain. There are, or at least may be, experts on what codes in fact say; and such 
experts could be quite useful in developing the initial list of provisions and later thinking about 
how that list might be augmented.'^ But ariy code of professional ethics is sinply a set of 
(morally-peraiissible) standards to guide men±)ers of the profession in ways ttey (at their 
rational best) want each other to conduct themselves. We have no procedure by v\Mch to learn 
v\tot members of a group will want at their rational best except by asking them v\tot they do 

381 



want challenging those answers with reasons, and seeing whether their preferences change. 
Their decisions, after due deliberation, are the best indicator of what the standards should be 
(though even that indicator is fallible). An expert may be able to spot contradictions, infelicities 
in expression, or provisions that have a history of causing trouble. What experts cannot identify 
is provisions that must be included in any code of ethics or provisions that (though morally 
permissible and competently written) do not belong in a code of ethics.^^ 

13.2.15. Don't expect "blue ribbon" committees to do much work. A "blue ribbon" 
committee, that is, a committee of those highly respected in a profession, may be useful for some 
purposes, such as protecting a proposed code of ethics from criticism. What blue-ribbon 
committees seem unable to do is write a code of ethics (or other document). There are several 
reasons for this. Three seem to be particularly important. First, most members of a blue-ribbon 
panel are likely to be too busy to write much. The code will be just one of many projects, one 
without (much) institutional support. Second, the skills of the highly respected in a profession 
generally are elsewhere, no profession having much opportunity to earn a reputation writing 
codes of ethics. Third, a blue-ribbon committee is likely to consist almost entirely of people 
successful enough to have hardened in their views and far from the work most members of the 
profession now do. Codes seem to be written instead by the "middling sort" of professional, long 
enough in the field to know what it is like but not so successful to be insulated from its 
pedestrian concerns; they are also likely to be disproportionate academics, even in fields where 
academics are not otherwise prominent. Many of these academics may (like the ACM's 
Anderson, 3.3, or me) come from outside the profession itself. 

13.2.16. Start planning early for dissemination^ education, and administration. A 
code of ethics is simply a piece of paper unless it enters practice. The first step to helping it enter 
practice is publication. "Publication" used to mean printing— in books, journals, or stand-alone 
pamphlets. It still does— in part. But web publication has also become an important means of 
dissemination. An organization that lacks its own web page may still place its code on other web 
sites. Among these others is IIT's Codes of Ethics Online (ethics.iit.edu/codes). 

Codes are, however, not necessarily used just because they are published. They can be 
daunting documents and, in any case, they are not self- interpreting. Practitioners need help with 
interpretation. Classroom instruction is one way to provide that help, whether in an 
undergraduate class or in a session at a professional meeting. Supporting documents, guides to 
the use of the code, are another way to help members of the profession use the code. Professional 
societies can also establish "ethics committees" to receive and resolve inquiries from members 
concerning the interpretation of the code. These resolutions ("opinions") may be formalized and 
published in the society's journal, in a collection (such as those of the National Society of 
Professional Engineers, the American Medical Association, or the American Bar Association), or 
in some other way. 

Providing authoritative interpretations of the code is part of its "administration" (as well 
as part of its dissemination). A professional society may also arrange for adjudication of disputes 
among members concerning "unethical conduct", for investigation of complaints against 
members concerning violations of the code, and for other quasi- legal procedures. Like licensing, 
however, quasi- legal enforcement is likely to generate opposition to the code, even if the process 
of enforcement is largely or entirely educational. Few people like to be told something they have 
done is unethical— especially if they are told so by an organization the judgments of which their 
colleagues or employers are likely to hear of and take seriously. 
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13.2.17. Establish a procedure for review and revision. Like people, codes age. What 
was up-to-date in 1970 may sound ancient even thirty years later. Part of keeping a code a part of 
practice is providing for regular reexamination. And even if codes did not age, they would be 
imperfect with experience revealing unexpected imperfections or confirming the existence of 
imperfections already suspected. While it is never possible to have a perfect code, it is always 
possible not only to improve what age has damaged but to improve what has aged well. The 
opinions of an "ethics committee" will, from time to time, identify provisions in need of 
rewriting and even, now and then, a provision that everyone can see should be there but for some 
reason is not. Where there is no ethics committee, the work of looking after the code can be 
given to a body with wider responsibilities, such as SWECC was, or to a temporary committee 
established, say, every five or ten years (for example, in every year ending with a zero). Such a 
body could carefully review the entire code, survey the users, or compare it with other codes, 
propose revisions based on what it learned, and then dissolve. Those who write a code of ethics 
should, if possible, send their governing body, along with the final code, a recommendation for a 
permanent or regularly reoccurring revision committee. That recommendation should include a 
procedure for moving from proposals for code's revision to final approval. The procedure should 
be, more or less, the same as the original procedure for adoption of the code.^^ 

13.2.18. Be wary of official translations of code. Translating an international code of 
ethics into the native language of those likely to use it may seem like one of those ideas to which 
no one should object— and perhaps it is. But it also has consequences worth taking into account 
before proceeding. A translation is, of course, never quite equivalent to the original. The same 
problems of choosing just the right formulation of a certain rule reappears all over again each 
time the code is translated into another language. Even software engineers fluent in both 
languages may disagree about whether the translation is close enough to the original. Each 
translation is a major commitment for those who undertake it. As the translations accumulate, 
revising the original code becomes a much more complicated process than it would be if the code 
were in only its original language. The translations should be tracked. Any amendment of the 
original should mean that within a few weeks or months all translations or, at least, all those 
posted on the internet, should be revised as well. Translation creates a problem of coordination, 
one that grows as the number of translations grows. 

13.3 Lessons for theory 

The story told here should teach us something about professions. But what it can teach us 
depends in part on what it is. I began supposing it to be a work of sociology. I was to describe, 
analyze, and (ultimately) understand a certain social process, the writing of a code of 
professional ethics. I have, however, come to think of the book more as history (because, as I 
reported in 1.5, 1 have come to trust the documents much more than the interviews). I can only 
offer a plausible narrative founded on the documents that events left behind (and interviews 
conducted well after those events). Even when "I was there" (as minor participant), I (the 
narrator) was not. My own memories granted no privilege even when I was trying to understand 
my own acts. However dirty the past, historians write with clean hands. 

What can history teach us about a social process when all we get out of a narrative is 
what we put in? That is one of those "philosophical questions" that give philosophy a bad name. 
Of course we will get out of a narrative only what we put in, but what-we-put-in is not the same 
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as what we consciously put it. So, for example, many of the lessons of 13.2 (concerning how to 
write a code of ethics) were new to me. I had not thought of them before I reached the end of my 
story and could see it (more or less) whole for the first time. I put those lessons into the narrative 
without realizing it. The lessons were as much a surprise to me as some of Euclid's theorems 
were when I first encountered them in high school. Simple axioms (and postulates), when put 
together in the right way, justify conclusions we do not anticipate when accepting the axioms. 
Even Euclid would doubtless have found some of the theorems his successors derived from his 
axioms surprising. We seldom know all that our acts imply. 

There is nonetheless a question about what my narrative can tell us of "the social 
process" of writing a code (or organizing a profession). The problem now is "social process" 
(not, as in 13.1, "history"). "Social process" is an abstraction, a product of social theory, 
something to be stated in general terms. What I have narrated are particular events. Though open 
to generalization, one narrative does not itself justify any (interesting) generalization. The 
justification of generalizations must await other similar studies. The lessons about social process 
we are to learn from this research are (in large part at least) a function of how research not yet 
imagined turns out. All one narrative can do is raise questions. Many of the questions take the 
form of a presumptive counter-example to a theory: such-and-such a theory says that all X's are 
Y's, but here is an X that is not a Y. Whether this presumptive counter-example actually is a 
counter-example will depend on whether the generalization it threatens can be revised to turn the 
example into no more than an interesting exception (or whether, upon re- examination of the 
evidence, the presumption simply disappears). A single narrative is, at best, an invitation to 
further research and theory. 

Does my narrative offer sociology any such invitations? I believe it does. It certainly 
suggests that we know less about how, why, and even when professions write codes of ethics 
than commonly supposed. Consider, for example, Larson's classic characterization of 
(nineteenth century) professions: 

The professional sector of the middle classes aspired to gain at least as much prestige as 
the most acceptable commoners (or, in America, the most successful businessmen) within 
this social stratum. This social ambition colored the professional project; it is likely to 
have inspired the ambition of most of the professionals who responded to the calls of the 
early organizers, for it is obvious that efforts to secure a relatively new market would 
have resulted in some benefit for the self-seeking individual.^^ 

If we treat this passage as a claim ahout all professions, including software engineering, we have 
reason to doubt that gaining the "prestige" of the "most successful businessmen" has much to do 
with the "professional project" (even "in America"). There is, first, the problem that none of the 
participants in writing the Software Engineering Code of Ethics ever expressed ariy interest in 
gaining such prestige, much less the expectation of gaining it through orgardzing software 
engineering as a profession Indeed, the disparaging comments regularly directed at Bill Gates 
(and Microsoft) are evidence that v\totever "prestige" software engineers want has little to do 
with success in business. The "prestige" software engineers explidtiy said they were seeking— if 
"prestige" rather than "deserved reputation" is the right word here— is the "prestige" that comes 
from belonging to a group known to do software engineering well. Those organizing software 
engineering as a profession (^parentiy) wanted to avoid the embarrassment of working in an 
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occupation that produced poorly constructed software behind schedule and over budget. They 
did not want to be associated with what they considered incompetence. 

Our research would not raise doubts about what the ambitions of those organizing the 
first professions were if Larson's claims about them rested on the sort of historical evidence that 
our does. But Larson has no such evidence. Behind her claims for what is "likely" or "obvious" 
is nothing more than the theory of economic rationality (that people act only, or at least largely, 
to serve their own private "self-serving" interests). Economic rationality explains much market 
behavior well. It does not however, explain all of it. It does not, for example, explain why self- 
interested individuals would buy life insurance, (anonymously) contribute to charity, support 
their aging parents, or engage in any number of other acts important in most economies but at 
least apparently "altruistic". Most thoughtful people, including most economists, understand that 
a (purely) "economic man" would be a monster to whom the term "rationality" would apply only 
in a sense (the economic sense). The professions, or at least the writing of professional codes, 
may exist (in large part at least) outside the domain of economic explanation (just as most other 
forms of altruism do). That, at least, is a reasonable inference from the story told here. 

But (it might be said) I have misinterpreted Larson. She did not claim that the "project" 
of self-interest was conscious; she merely spoke of it "coloring" the (conscious) project of 
establishing a profession. Indeed, she explicitly noted that sociological theory does not 
understand "project" in the ordinary sense (as a "planned undertaking"): 

it does not mean that the goals and strategies pursued by a given group are entirely clear 
or deliberate for all the members, nor even for the most determined and articulate among 
them. Applied to the historical results of a given course of action, the term "project" 
emphasizes the coherence and consistence that can be discovered ex post facto in a 
variety of apparently unconnected acts.^^ 

In other words, "project" is probably the wrong word for wtet Larson has in mind 'Tendency" 
would be much better for two reasons. First, "tendency" does not suggest planning or even 
consciousness of the outcome in questiorL Second, "tendency" allows for degrees (just as "color^' 
does). Tendencies can be strong or weak {vMle projects just are or are not). 

Because a tendency can exist in ariy nurnber of degrees, dispDving its existence is much 
harder than disproving the existence of a project For exanple, suppose (as I have claimed) that 
this book shows that writing the software engineering code of ethics was primarily (at least at the 
conscious level) an altruistic undertaking. Larson might agree and yet claim that she can show 
(using apparently unconnected acts) that it is 'liMy" that self-interest "colored" the project to 
some degree. Who can doubt that? The interesting question is: To what degree? And the story 
told here suggests that self-interest can offer little insight into the acts recorded here (or at least 
little beyond what altruism already provides). Now, there may be another way to tell this story, 
one respecting the evidence at least as much as this one does but leading to (something like) 
Larson's conclusion. That cannot be ruled out a priori. But neither can it be assumed a priori. 
We are certainly not entitled to draw conclusions from such a possibility until it exists in a form 
that can be read, checked, and appraised. 

I have picked on Larson only to make a point I could have made against many 
sociologists writing on professions, including many of the most important The general tendency 
of all the social sciences is to look for explanations beyond subjective purposes. Sometimes this 
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search ends in an important insight (such as "the invisible hand" of economics). But sometimes it 
does not. Subjective purposes explain some events as well as they can be explained. The social 
sciences then have nothing (interesting) to add; there is only history. 

I believe the best explanation of the events narrated here are the conscious motives of the 
participants. But I might be wrong. From tiie beginning, I knew that tiie events I— as 
participant— knew of were not the whole story. One reason for interviewing participants was to 
fill in parts of the story that the documents did not reveal. I was concerned, for example, about 
tiie possibility of secret meetings at which "the real decisions" were made, rendering the process 
I had observed mere epiphenomena. There may have been such meetings, especially when the 
ACM withdrew from tire Software Engineering Coordinating Committee (SWECC). But I have 
found no evidence of "midnight meetings in smoke-filled rooms" at which decisions were made 
for reasons tiiat could not bear the light of day. No one seems to have thought, or at least 
suggested, that the motives of participants even at the meeting at which the ACM voted to 
withdraw from SWECC differed in important ways from those that appeared in official reports or 
at the meetings for which we have the minutes, much less that the decisions taken in closed 
meetings require explanation in terms of processes not wholly conscious. When I asked about 
"the politics" of this or that event, I heard about bad decisions, hasty decisions, ill-informed 
decisions, but nothing that required me to look for social dynamics bypassing what people knew, 
intended, and consciously did. The reasons given in public seem to have been much like the 
reasons given in private and seem to explain the acts of the individuals in question. There does 
not seem to be any reason to "go deeper". 

Of course, my focus has been on tiie writing of a code of ethics. Perhaps writing a code of 
ethics is not important enough to be subject to the social dynamics of concern to serious social 
theory. I must admit that possibility. While I have argued that codes of ethics are central to 
professions (1.4), that centrality remains controversial. For most sociological theories, tiie code 
of ethics is of little or no significance. The body of knowledge, the curriculum, and licensing are 
much more important.^^ Because most sociologists may igect n^^ claim for the inpjitance of 
codes, it is worth recalling that I have not ignored those features of profession most sociologists 
consider central. My story includes much about the body of kno^A^edge, the curriculum, and 
licensing. Yet, there was nothing in n^^ story to suggest that the code of ethics was uninportant 
or that development of the body of kriov\dedge or the curriculum proceeded in a fundamentally 
different way. The one surprise in niy story is licensing, the primary means of achieving tte 
marlffit monopoly at v\Mch marry sociologists assume professions aim Licensing was so 
controversial among software engineers (or, at least, among computer scientists) that the ACM 
withdrew from SWECC just because SWECC seemed to provide support for licensing. (12.4) 
Licensing, though important, was important in exactly the way social theories like Larson's say it 
should not be." 

Whether history presents a good counter-exanple or not, it may raise new questions for 
research. For me (as a philosopher), the most interesting question that niy narrative raises is why 
so many philosophers ^Dpear in this story of software engineering— and v\^ they ^Dpear so 
prominently. Though lawyers outnumber philosophers ten to one in the population as a v\tole, 
philosophers outnumber lawyers in the writing of the Software Engineering Code of Ethics. This 
was tme even though Gotteitem sought out lawyers (and actually recnrited one. Barber). Of the 
philosophers, two (Weil and I) were (more or less) a single typioduct of this study. We would 
not have been there but for the research. Gotterbam recnrited two others (Fodor and Sullivan), 
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though not because they were philosophers. Gotterbam also recruited one other, Fairweather, not 
because he was a philosopher, but as a member of the Centre for Computers and Social 
Responsibility (CCSR). Weckert volunteered, but as a computer scientist not as a (former) 
philosopher. Philosophers were not part of Gotterbam' s plan (even though Gotterbam himself 
had once been a philosopher). The philosophers just accumulated.^" They also seem to have been 
present in disproportionate numbens for the writing of the ACM Code of Ethics.^ ' Why? What do 
philosophens contribute that "mere" conpjter professionals cannot? Or is the explanation of their 
unexpected numbens not v\tot they contribute but v\tot they find attractive? Does the pattern 
reappear in other professions? 

There is a similar question about the role of academics. They seem to have a much larger 
role in the writing of the SofbA/are Engineering Code (and, indeed, in the writing of the ACM 
Code) than their absolute number would lead us to expect Even in Mechler's little group, they 
accounted for more than half. (Of the seven, only Mechler, Norman, and Sullivan were not 
academics at the time they worted on the Code— and Sullivan was a former academic v\Mle 
Norman worted on the staff of a university and even taught a course most semesters.) 
Gotterbam' s informal drafting committee at CCSR (and his executive commitiee as well) 
consisted entirely of academics (though each had considerable experience of practice) . Even the 
original list of SEEPP volunteers (1993) seems to have had a disproportionate number of 
academics (17 out of 29). Nothing in the documents I have examined suggests a tension between 
academics and non-academics such as exists in some parts of engineering— perh^:s because (as 
we saw) the boundary between practitioners and academics in software engineering is quite 
porous.^ ^ The academics do not seem at all interested in seizing power or using the code to 
feather their own nest. They seem to be there because they have more time to devote to the 
work— or, at least better control over the time they have. But perhaps they are present in 
professional organizations in unexpectedly high numbers for other reasons too. What might those 
be? 

1 3.4 Some lessons for researchers 

Are there any practical lessons for those who might be considering similar research, that 
is, research into the writing of codes of professional ethics? I believe there are— though, as with 
the lessons for 13.2, these are best treated as "things to consider". 

13.4.01. For some purposes, a telephone interview is no substitute for an in-person 
(on-site) interview. One review of our original NSF proposal suggested that we interview by 
telephone rather than in-person. The reviewer cited his (or her) experience for dismissing in- 
person interviews as an unnecessary expense. After reviewing the (quite small) literature on the 
question and consulting social scientists we knew who did open-ended interviews, we concluded 
that the reviewer must have been relying on experience with survey questionnaires rather than 
open-ended interviews. I now have four more reasons for that conclusion. 

First open-ended interviews tend to last much longer than survey interviews done over 
the phone. The typical phone survey seldom lasts half an hour. Our shortest interview— with 
Weckert— was just over an hour. I think there is a practical reason for the shorter duration of 
phone interviews. Twice during my research, I tried (something like) a phone "interview" (once 
with Douglas and once with Chikofsky). Each interview was at the suggestion of the interviewee 
after I contacted her or him about an in-person interview. In each case, the interviewee promised 
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to fill me in on "background politics" (as a supplement to the formal interview to occur later) 
and, in each case, the phone call lasted less than a half hour. The phone interview seemed to run 
out of energy in a way in- person interviews (generally) do not. Both times I was surprised at how 
tired I felt after the interview, especially how sore my arm and ear were. The interviewee likely 
felt the same. This, then, is anecdotal evidence that phone interviews may have to be shorter than 
in- person interviews in part at least because holding a phone to the ear is more tiring than 
ordinary listening. Perhaps too, there is another factor, the special attention required to listen to a 
speaker without the facial cues, gestures, and so on that one has when conducting an in-person 
interview. 

Second, the in-person interview gives the interviewee a better opportunity than a phone 
interview to assess the interviewer. The interviewer has the same opportunity. The in-person 
interview can build a relationship in a way a phone interview cannot. A disembodied voice is not 
as easy to trust as a full human being. Several of my interviews ended with the interviewee and 
me together going to lunch or dinner. The interview was over, but we had discovered enough in 
common to continue the conversation. Most of the interviewees who later sent me documents, or 
answered questions I emailed, even several years after the interview, were the ones I shared a 
meal with. The in-person interview paid off in ways I would not have predicted. 

Third, the relationship between interviewer and interviewee is different when they meet 
in person "on-site" (that is, at, or at least near, the home or office of the interviewee). There is, of 
course, the honor implicit in the time and money that the interviewer has spent to do the 
interview in person. A phone interview cannot do the same honor. The honor is much increased 
when the interview is convenient for the interviewee but far from the interviewer's home.^^ (Is 
the honor doubled if there are two interviewers rather than one?) 

Fourth, I conducted about half the interviews in the interviewee' s office (academic office, 
law office, laboratory of free, orthelite). I leaniedsorriething about the environnient in v\Mch the 
interviewee worted that I could not from a phone interview or even from an interview in niy 
hotel room or at some neutral location For exanple, v\ten I eriered the Software Engineering 
Institute (SEI) to interview Barbacd, the first thing I noticed (^:art from the inpressive scale of 
SEI' s modernist building) was its security. Thou^ located on a university carrpjs, it was plainly 
not an (ordinary) academic building. There was just one unlocted entrance, with a guaii just 
inside the door, a large desk before him, and a book on top of it into which visitors had to enter 
their name, "conpaiiy", time of arrival, and host. After I entered that information, the guard 
phoned Barbacci, issued me and niy graduate student each a "guest badge", andastedustowait 
until Barbacci came to escort us upstairs. When Barbacci arrived, he too was wearing a badge, 
but his had his name and photo on it The security procedures at SEI were even stricter than at 
IBM' s Watson Research Center (perti^:s reflecting SEI' s relation to the Department of Defense 
or just its location on a big-dty street) . That introduction to SEI helped me ^Dpredate Bariacci' s 
informality (and candor) v\ten we finally reached his office and began the interview. 

13.4.02. Think twice before doing in-person on-site interviews. I have nonetheless 
come to sympathize with that anonymous reviewer who thought the in-person on-site interviews 
might not be worth the cost. Scheduling an interview took about as much time as the interview 
itself. Travel consumed much more time, especially after the changes in airport security that 
followed September 11, 2001. Anyone thinking about doing research involving interviews 
should think about whether in-person interviews are worth the time— as well as the expense— of 
travel to distant locations. While I think my interviews were worth the time and expense, some 
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interviews may not be, especially if the questionnaire is relatively short, the questions multiple 
choice or at least short answer, and the information to be solicited not very personal. Interviews 
at conferences also have attractions that interviews on-site do not, so long as there are several 
people to be interviewed there, or the site is close to the interviewer's home, or the interviewer 
would be there even if no interviews were scheduled. 

13.4.03. Take notes no matter what. When we prepared our NSF proposal, we worried 
a good deal about whether to tape interviews or just take notes. Our social scientists advised us 
that taping would not significantly reduce the spontaneity of the interview. We (the philosophers) 
nonetheless had doubts. Now, having done (much the same) interview with and without taping, I 
agree with the social scientists. Our shortest interview, our first (Weckert), was not taped 
(because we did not think to bring a tape recorder); some interviews were not taped because the 
recorder failed to work. But no interview went untaped because the interviewee refused. Our 
interviewees, like most of those our social scientists had interviewed during long careers, did not 
seem to find the tape recorder intimidating. We did, however, have a few occasions when, in the 
middle of the interview, the interviewee asked to have the tape recorder turned off. In each case, 
the interviewee wanted to speak candidly about a particular individual, providing background for 
what was on the tape. In each case what was revealed was not a scandal but the interviewee's 
personal judgments, something (he or she thought) I— but not the world— should know. After the 
revelation, with perhaps some follow-up questions (and answers), I switched the tape recorder on 
again and continued the formal interview. 

The problem with taping interviews was not that taping intimidated our interviewees but 
that it was never entirely convenient. There were always the awkward few minutes at the 
beginning of the interview when we tried to make conversation while seting up and testing the 
machine to make sure it would pick up the interview. That over, we could begin in earnest. These 
preliminaries were, however, not the only inconveniences of taping the interview. Tape for the 
portable recorders we used could not be made to last over 90 minutes while our interviews 
tended to last about 120 minutes. The tape would, then, have to be changed at least once (twice if 
we used a higher fidelity setting). If we heard the recorder click off, we would have to stop the 
interview to change the tape, breaking the interview's flow. Sometimes, however, the interview 
was so engrossing, or the click so quiet, that we missed it. Sometimes we soon noticed that the 
recorder had gone off, changed the tape, and switched the recorder back on. Sometimes we did 
not realize the tape had run out until the interview was over. (Once we even discovered that we 
had somehow failed to turn the recorder on.) We soon learned to treat the tape as auxiliary to our 
notes. Even when I interviewed alone, I took notes (though making notes slowed the interview 
process and broke the flow almost as much as, and much more often than, stopping to change 
tapes did) .^^ 

Another advantage of notes over t^:e is that turning notes into an "interview report" is 
much easier than turning t^:e into one. Transcrihang a t^:e is slow. Few people can type as fast 
as people talk. TranscriMng usually requires stopping, reversing, and r^aying the t£^ once, 
twice, or even several times, every few sentences. Few academics have the patience for 
transcriptiorL Giving the job to someone not present at the interview, even a commercial 
transcriber, has risks of its own, however. Transcrihang is not necessarily reliable. Sometimes 
cmcial words are not clear on the t^:e (even though they were clear to the interviewers). The 
transcriber should, of course, note ariy doubts in the transcription, allowing the interviewer to 
correct the text But sometimes what the transcriber tates to be clearly one thing is in fact 
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something else. That will not be indicated in the transcript. The only way for an interviewer to 
catch it is for him to read the transcript while listening to the tape— and even then he may miss 
the change. If he does not catch it the interviewee may— but only if the error is inconsistent with 
what she meant to say. 

13.4.04. What counts as "the interview" is not a question of fact. Most of the 
interviews we conducted exist (or, at least existed) in at least four versions (apart from the event 
itself). We have discussed two versions already. First there are the notes one of the interviewers 
took and second (with a few exceptions) the tape of the interview. The notes (sometimes with 
assistance from the tape) were then turned into a formal document (the third thing that might 
count as "the interview"), our reconstruction of what happened. When I worked with a graduate 
student the formal document was sometimes close to a transcription. When I worked alone, the 
interview document was really a summary (with a few good quotations), much shorter than a 
transcription of the interview would have been.^^ Qn^ there was a formal document the 
interviewers agreed on, I sent it ("the edited interview") to the interviewee, v\to was to check it 
Interviewees occasionally found that we misreported v\tot they had said, but more often 
corrected their own grammatical enors or enors of fact Occasionally, they toned down a phrase, 
substituted a formal expression for slang, or otherwise treated the document as a rough draft of 
their final remarls. What they sent back, we called "the ^proved interview". 

According to the "protocol" (the explanation of the research that we gave to the 
interviewee along with the consent form), we were supposed to mark corrections interviewees 
made with "Interviewee's Comment". We interpreted the protocol to mean we should mark the 
corrections v\tea but only when, we disagreed with the interviewee about v\tot was said at the 
interview and the correction was more than editorial. We never had such a disagreement We 
interpreted the protocol this way because it allowed "additions" to be treated in exactly this way. 

I naively supposed that the "approved interview" was "the interview" (and the earlier 
versions were merely stages in achieving that final document). My advisory board, or at least the 
two sociologists on it disagreed. The approved interview was one thing, they noted, something 
careful and contrived, while the transcription (or tape) was something else, the (relatively) 
spontaneous expression of the moment. The factual and grammatical errors, the slang, the heated 
expressions, all told something about the interview itself (and so about the interviewee) lost in 
the revisions. While I conceded their points, I did not have the same concern about preserving 
the moment of the interview. The point of the interview, as I saw it was to get the interviewee's 
help in reconstructing what happened. I preferred an interviewee's considered judgment to 
spontaneous expression.^'' I thought that the interviewee had a right to shape the interview to his 
orher satisfactiorL Forme, the interview was not the original oral event but the final (approved) 
document" 

I was so sure of that that— for at time— I threw out n^^ notes as soon as the interview was 
^Dproved Once I had the ^proved interview, the notes seemed to have no further use. Indeed, 
they might in the wrong hciris, threaten the confidentiality I had promised I would have erased 
the interview t^:es as well if I had thought of it But I had initially bought such a large package 
that I threw the t^:es into a box under niy desk once I was done with them, thinking I might 
reuse them later (never supposing that within a few years digital recording would mate t^:es 
obsolete). The t^:es still exist only because the advisory board, shoctedv\tenI told them v\totl 
considered "the interview" and v\tot I intended to do with the t^:es v\ten I got around to it 
enphatically advised me to save them^ ^ 
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Having saved the tapes, our research group faced a problem not anticipated. Along with 
the consent form, each interviewee had received the research protocol explaining the research in 
greater detail. For our purposes (though perhaps not for the IRB's), the protocol was part of the 
consent form and as morally binding. What the protocol said about the tapes was: 

For our own research purposes, and for the benefit of future historians, we will 
tape record or take notes of this interview. We will transcribe or write up the notes and 
send you a copy for comment. You may suggest corrections or additions. Your 
corrections will be inserted at the appropriate point, but marked as "Interviewee's 
Comment". We will do our best to keep the text of your interview confidential— unless 
you notify us, in writing, that the interview may become part of our Public Archive. 

There is nothing in the protocol about what will be done with the tapes of the interview (except 
for the reference to "the benefit of future historians"); and there is nothing at all about what will 
be done with the notes.^^ There is, however, a distinction drawn between "your v\tole interview" 
and a "summary": 

In addition, we plan to prepare a summary of your interview v\Mch— sutgect to your 
written peraiission (and dso sutgect to the written peranssion of ariy living others naned 
in the summary)— may be placed in our Public Archive as part of a database accessible 
on line. Should you give us written permission to place your v\tole interview in the 
Public Archive, this summary would also be placed in the on-line database. Nothing 
placed in our Public Archive is confidential. You may withdraw your material from it at 
any time up to the moment it is placed on line. Sinqiy send a notice in writing to: [CSEP] 

The advisory board interpreted the "whole interview" to be the t^:e— and the approved 
document, especially v\ten short, to be the "summary". 

WMe there is something in the advisory board' s interpretation of the protocol worthy of 
Solomon, there is also the sort of problem that arises when someone uses Solomon' s means (for 
exanqie, threatening to cut a bafcy in half). The protocol says that "the portions of interviews for 
v\Mch you have requested confidentiality (including your subsequent commerts) will be placed 
in a Research Archive available only to registered arid ^proved researchers v\to will be bound 
by the same rules of confidentiality as the original project researchers." None of our interviewees 
has requested confidertiality for the tapes— in peat no doubt because we gave them the 
uip:ession that we were only going to use the t^:es as aids to memory ("[for] our research 
purposes"). Should we teep the t^:es confidential until January 1, 2020 (when "this Research 
Archive will have the original material removed and personal references restored to become a 
Historical Archive available for use by the general public and future historians")? Qr should we 
teep the t^:es confidential until the interviewee gives pennission to reveal them (or until the 
interviewee dies)? If the interviewee signed a consent agreement allowing the "interview" to be 
put online, may we put the t^:e online? (When we wrote the protocol, putting t^:es online was 
not technically feasible; now it is.) 

For now, we are even asking consent to put "the summary" online. While no one has 
refused to give consent, about a third of our interviewees have still not responded one way or 
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another to our request. Should we put these summaries in level 1, 2, or 3? What about the 
approved (or merely edited) interviews? The Advisory Board is still considering these questions. 

13.4.05. Not all interviewers are equal; an interview teams including a philosopher 
may be better than one consisting entirely of social scientists (anthropologists, sociologists, 
political scientists, historians, or the like). I conducted about a third of the interviews with a 
graduate student in sociology, discussing the interviews with him afterward. I soon noticed that 
we did not pay attention to the same aspects of the interview. I recalled arguments, descriptions 
of career, and names of organizations; he recalled tone of voice, gestures, odd expressions, and 
the names of individuals mentioned during the interview (evidence of, he said, "networks"). 
During the interviews I sometimes departed from the questionnaire to learn more about how this 
or that job was done, the way one organization was related to another, or other details I thought 
my interviewee particularly qualified to help me understand. My graduate student would ask 
such questions as, "How do the people that are supposed to adhere to it see the code?" or "How 
much of this was driven by concern for the public and software engineer's relationship with the 
public and their safety?" He did not ask those questions because he believed the interviewee 
would know the answer. He was simply interested in seeing what sort of answer the interviewee 
would give. He was trying to understand the interviewee.^" 

The difference between our two interviewing styles strifes me as emliematrc of the 
difference between philosopliy and sociology (and so, between most philosophers and most 
sodologists). I do not claim that I was a better interviewer than he was— or even (v\tot is more 
liMy) that he was a better interviewer than I was. What I do claim is that we were somev\tot 
different interviewers liMy to uncover somev\tot different information Insofar as I am right 
about the difference and its relation to our different disciplines, having a philosopher 
interviewing along with a social scientist seems liMy to inprove the interview. Periiaps much 
social-science research would be better if philosopheis were part of the research team not only 
hdpng to sh^:e questions or interpret data but hdpng to collect the data too. Philosophers terd 
to remind social scientists of the (substantial) contribution of reason to human conduct; social 
scientists, of that part of human conduct reason cannot entirely explain 

13.4.06. Think of research like this more as journalism than as ordinary social 
science. The protocols, consent forms, and rules concerning confidentiality now governing social 
science research began in medical research, a response to a series of scandals. Medical 
researchers undertook to avoid repeating not only the crimes of Nazi medical research but also 
the deception of the Tuskegee experiments, quasi-voluntary research on prisoners, 
experimentation on patients and wards of the state without informing them, and other once- 
common but now clearly objectionable practices. Much social- science research resembles this 
sort of medical research insofar as the research subjects are young, unduly subject to pressure 
(students in a class, for example), poor (and so easily won over with small incentives), 
uneducated (and so easily misled), or otherwise especially vulnerable. Such vulnerable subjects 
of research in the social sciences need the protection of an IRB for much the same reason that 
they need that protection when subjects of medical research. 

Our interviewees do not much resemble such research subjects. Our interviewees were 
much more like the "newsmakers" journalists interview. They were (and remain) relatively 
sophisticated adults not likely to be in awe of their interviewers. They were, for example, quite 
capable of asking to have the tape recorder turned off for a time when they wanted some part of 
the interview to be "off the record". For some of the interviewees, such a Bill Wulf, then 
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President of the National Academy of Engineering, it was the interviewers who were the ones 
likely to be in awe. Most of our interviewees were far enough along in their careers, and 
important enough in their discipline, to risk little should they happen to give offense. None was a 
graduate student or even an untenured assistant professor. They were not (in any significant way) 
dependent on the interviewers. 

The First Amendment legally protects from IRB regulations the work of journalists based 
in a university in a way it does not protect other university- based researchers. Behind that legal 
protection is a moral argument balancing the need to protect the subjects of journalistic research 
against the importance of what may be gained by exempting the research from IRB regulations. I 
think the same moral argument applies to the research we did. What we could learn from the 
interviews was important; the vulnerability of our interviewees was low. 

That is not to say that the sort of research we did should be entirely exempt from (formal) 
IRB review. Though our research group was (and remains) relatively conversant with research 
ethics (a majority having served on an IRB and several of us having as well a scholarly interest 
in the subject), we benefited from having the IRB look at our research plan. Researchers, even 
those with a strong commitment to research ethics, have a tendency to overlook or underestimate 
ethical difficulties in their own research. Having the IRB look over our research plan and make 
suggestions certainly helped to compensate for our (natural) partiality. The IRB identified 
questions we needed to think through (for example, how much confidentiality to provide 
documents). We might have benefited even more from IRB review had its regulations 
distinguished between our sort of research and the standard social- science research involving 
human subjects. 

13.4.07. Ordinary standards of confidentiality for medical documents should not 
(automatically) apply to "newsworthy" documents generated for another purpose. We may 
divide the documents collected, placed in the archive, and used (or at least useable) during the 
writing of this book into at least six categories. For each category, the weight of reasons favoring 
confidentiality is different. 

Part of the archive consists of articles published in a newspaper, magazine (including 
some sent out to subscribers by email), or online (for example, an lEEE-CS website). These, of 
course, need not be considered confidential at all. They may be cited in the way any public 
document may. Closely related to these are official reports widely distributed but not published 
(for example, some of Gotterbam's reports to the Joint Steering Committee, distributed to a large 
mailing list beyond the Committee without any indication that they were to be kept confidential). 
I see no reason why these should not be treated as if they were public documents (even though, 
strictly speaking, they are not). 

A third category contains the broadcast emails (without any indication that they were in 
any way confidential). These differ from official reports only in lacking a certain formality. 
Insofar as they lack formality, they are likely to be less careful in expression. They are more 
likely to include intemperate remarks, grammatical errors, and other signs of spontaneity. 
Gotterbam plainly began thinking of the working group's list as "closed" (much as one might 
think of email circulated among employees in a firm). That was why, initially, he took care to 
prevent spamming (by not allowing automatic retransmission of any message sent to the list). 
While spamming turned out not to be a problem, getting people to use the list— and later the 
listserv— was. As he sought to make using the list (and listserv) easier, he incidentally opened it 
to personal messages not intended for broadcast and therefore had to remind users of the 
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distinction between replying to individuals and to "all" or to the listserv. Gotterbam has given 
consent to use his broadcast emails freely. Mechler, Miller, and most of the others who 
contributed important broadcast emails have done the same. One important contributor to the list 
Prinzivalli, is dead; we felt justified in presuming his consent to be quoted (especially since 
Gotterbam considered his contribution to the Code important). We have therefore not had to 
decide the hard question whether the newsworthiness of this category of email justified quotation 
where consent was deliberately withheld or just negligently not granted. 

I have not please note, justified quoting these emails by appeal to Gotterbam' s initial 
notice (now apparently lost) that a research group at IIT would be monitoring SEEPP's 
communications as part of NSF-funded research. I have not appealed to that notice because I 
have come to think that the time between it and most of the emails was too great— and that in 
any case, the notice seems not to have been given in a way likely to be noticed. While no one we 
interviewed objected to the use of his or her emails in writing this book, no one recalled the 
notice, even those who had been put on a SEEPP list in late 1993. Consent should not be 
supposed to last longer than the memory of it. I think it reasonable to suppose that the memory 
would last a few months, perhaps even a year, but no longer than that without reminders. Most of 
the private emails quoted in this book date from a later period. Hence, we have abandoned any 
appeal to "original consent". 

Two other categories of email in our archive have forced us to face the question of using 
email where we do not have consent (but where it was not refused). One of these categories 
consists of emails to Gotterbam (or Mechler) from individuals on one of Gotterbam's lists who 
chose to write Gotterbam (or Mechler), not the list This is a disparate category. Often, the 
reason for not using the list seems to have been doubt that it was working, not a desire to keep 
the communication confidential. Sometimes the reason for not using the list was that Gotterbam 
had not used it for example, because he was some place where he could not use it His 
respondent simply pressed "reply"— without thought of confidentiality. Gotterbam occasionally 
forwarded emails of this sort to the list when he was again in position to do it suggesting that he 
too did not suppose private communication necessarily implied confidentiality. None of these 
correspondents seems ever to have complained of the re-transmission. 

Sometimes the reason for writing privately was that the subject discussed was not 
appropriate for the list for example, an editor's response to Mechler joumal submission. 
Sometimes it is not clear why the writer chose a private message rather than the list. For all we 
know, he may have used Gotterbam's address, rather than the lists, because he (or his email 
program) recalled the one and not the other. Where we have quoted emails in this category and 
not had consent to do so, we have avoided giving the writer's name. We thought this sufficient to 
protect the author's rights (especially when the author in question was identified in Gotterbam's 
email only by a common name and an expired— and opaque— email address). 

Student contributions to the Code, whether going to the list or to Gotterbam alone, posed 
a special problem. Some of the students (Kanko's) had no choice about contributing. They had 
an assignment and their instmctor passed the results to Gotterbam. These statudents certainly 
have a right not to have their names connected with what they wrote. But what they wrote was, I 
thought too important not to quote. I have therefore quoted (or paraphrased) them— without 
giving a name (or any other information likely to reveal an individual's identity. Other students 
(such as those at Eau Claire) wrote at the suggestion of their instmctor but (apparently) without 
any pressure to write or expectation of confidentiality. They would nonetheless probably be 
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surprised, and not necessarily pleasantly surprised, to find themselves quoted by name in a book. 
I have therefore also quoted them anonymously. But anyone who checks the endnote and knows 
the student from class should be able to figure out who he is. This seems harmless since what 
they wrote was intelligent, not something to be ashamed of even if they have changed their 
minds since— and they wrote it to a stranger without any promise of confidentiality. 

The sixth category of email consists of "quotations". Some of these are true quotations, a 
few lines taken from a larger document, but most are whole documents the email program 
automatically placed below the response. Whether the original writer intended the email to be 
confidential, it is not confidential once quoted in a document not itself confidential. Yet, I did 
feel a residual duty to say as little about the source of the quotation as consistent with making an 
appropriate use of it. Where the author writes in an official capacity, especially where the source 
of the email is important, I have generally named the author. Otherwise, I have not. 

In discussing quotation of email, it is easy to confuse two issues, copyright and 
confidentiality. I believe my quotations are all either "fair use" or covered by consent actually 
obtained. Though copyright has not been a problem, I could have avoided copyright issues 
altogether by paraphrasing rather than quoting directly. I have often preferred to quote directly to 
preserve the immediacy, pungency, or individuality of the original. I have paraphrased only 
when I saw no advantage to direct quotation. But, even if I had paraphrased every email, I would 
still have had much the same problem of confidentiality. Confidentiality concerns content as 
much as expression. People have a (limited) right to control to whom they reveal what they 
think— whether their exact words or merely the sense expressed. 

13.4.08. One way to compensate for treating this sort of research as journalism 
rather than "human subjects research" is to have an advisory board that includes 
representatives of those under study. In anthropology, it is today common to create a 
committee of "the community" (a rural village, say) to oversee the study of that community. 
Such a committee is a way to maintain good relations with the community (by, for example, 
providing insight into the culture before the researchers commit some gross indiscretion). It is 
also a way to protect the community from the researchers (by, for example, working out in 
advance the rules for conducting the research). The community committee considers questions 
not likely to arise in any ordinary IRB . For example, the community committee might make it a 
condition of research that no lodge songs be taped, transcribed, or otherwise carried beyond the 
lodge. Because the community committee provides this sort of control over research, it can 
vouch for the researchers, easing their way into a community that might otherwise be much less 
cooperative.^^ 

Our advisory board functioned in much the same way even though its membership was 
only in part drawn from the community under study. Having advisors helped in obtaining 
documents. Gotberbam's contribution was, though enormous and irreplaceable, no surprise. We 
had built it into our original plaa Engd' s contribution, though much smaller, was both inpjrtant 
and a surprise (though, in retrospect, it seems we should have anticipated much of it). Engd 
understood the lEEE-CS in a way no one else on the commitbee did, especially the relations 
among various commitbees, certain IEEE terannology (for exanqie, the difference within the 
IEEE between 'IEEE standard" and 'IEEE Starriard"), and ways in v\Mch we might 
unintentionally give offense by some seemingly urdnpjrtant choice of words (for exanple, by 
refening to associate members as "mere associate members"). He also loaned me one hard-to- 
find report from his own files, reminded the advisory board of the larger institutional context in 
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which the process we were studying took place, and provided the name and phone number of 
sources from whom certain documents might be obtained. 

Most important here, Engel— as well as Gotterbam and Bernstein— spoke for the 
community under study concerning what emails (and other communications) were appropriate to 
quote in this book, what should only be paraphrased, and what should only be mined for 
information. They also helped us decide when it was appropriate to give the source's name. 
Their concern with confidentiality was not primarily with privacy (as it was for the IRB) but with 
not (unnecessarily) hurting the feelings of people or entire organizations with whom they might 
later have to work. Often, the way to satisfy their concerns was not, as at first I supposed, to 
suppress the quotation in question, but to enlarge it or otherwise provide more context. They did 
not seem to mind the light of day falling on what they or their colleagues had done; what they 
minded was having what they had done put in a false light. Only when the question of 
confidentiality concerned a private individual who wrote directly to another private individual 
(or to an office holder in some private capacity) did they express concern about confidentiality 
similar to that the IRB typically expresses. 

13.4.09. There is always another interpretation. On January 6, 2004, Mechler sent me 
a dramatic reminder of how different interpretations of the same event can be. The story told 
here is of well-meaning people devoted to a good cause and working in ways more or less 
meeting standards of good conduct. Yet, after reading all but this chapter, Mechler posed six 
"ethical questions" about the conduct I described— and asking what I thought. What I thought 
was, "Here are six questions my readers should think about": 

1. If one volunteers, whether recruited or not, shouldn't one give time to the project 
or resign? 

2. If one is working on a project with a clear objective[,] should one's ideas rule how 
the work is done or what work is done or should the objective [rule the work]? 

3. Is it ethical for Don to change the code without the original developers being 
involved? 

4. Is it ethical to develop the code using a political model instead of an ethical 
model? 

5. From the beginning to the end of your chapters it appears like the leaders want 
certain people, stack the membership, instead of volunteers. I know of at least two calls 
[in lEEE-CS publications] for volunteers and ACM probably had one also. How many 
volunteers were from these calls and how many hand picked? Or maybe the practitioners 
of SE didn't volunteer for the task. How many volunteers were there? Y ou never give a 
count.^^ This point is related to question four [4] above, political or ethical? 

6. Is it dMcal to force a method on rmlity, method fit to reality vs reality fit to 
method? I have been trying for years, with p^:ers and exanples, to depict another 
method to use, especially in social issues but have had little success. 

There is a popular saying: "Hindsight is 20/20". It asserts, in effect, that once we know 
that a decision turned out badly, we know not only v\tot we should not have done but also v\tot 
we should have done instead The saying is wrong. For hindsight to be 20/20, we would have to 
know not only v\tot we do know, how things turned out, but also how things would have turned 
out had people conducted themselves differently (for exarrple, v\tether the Code would have 
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passed if Gotterbam had followed an "ethical model" instead of a "political model"). We cannot 
know the outcome of choices not made without going back into the "history lab", 
reprogramming the world, and watching the alternative history reveal itself. Unfortunately, we 
have no history lab. We are stuck with one set of events and our opinions about what-would- 
have- happened- if. Some of those opinions may, upon closer examination, prove untenable. 
Others, perhaps both Mechler's opinion (that the process could have been more "ethical" and 
still succeeded) and Gotterbam' s (that it was a near- run thing as it was and any less political 
document would have failed), might, upon close examination, turn out to be equally consistent 
with what we actually know (though at odds with each other). Seldom does history tell us who is 
right. Hindsight is not much better than foresight.^^ 
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NOTES 

^ Much of sections 13.1 and 13.2 have been published as "Eighteen Rules for Writing a 

Code of Prof essional Ethics", Science and Engineering Ethics 13 (July 2007): 171-189. 

^ G. W. F. Hegel, Philosophy of History, trans, by F. Sibree (Colonial Press: New York, 

1900), p. 6. 

^ Hegd, Philosophy of History, p. 26: "The history of the worid is not a theater of 

happiness. Periods of happiness are biank pages in it . . " George Eliot said it better (but a bit 
later): "The happiest women, lite the happiest nations, have no history." The Mill on the Floss, 
bk.V,cli.4. 

^ For details on the inpjrtance of record keeping even in the eariy history of engineering, 

see n^^ Thinking like an Engineer, esp. pp. 8-12. The past that engineering uses may well not 
count as "history" (strictly speaking) because it often does not take the form of a narrative. It is 
"history" only in the lose sense of "the past". 

^ Kari Marx, The Eighteenth Brumaire of Louis Napoleon, in On Revolution, edited and 

translated by Saul K. Padover (McGraw-Hill: New York, 1971), p. 245: "Hegel remarks 
somewhere that all great worid- historic facts and personages appear, so to speak, twice. He 
forgot to add: the first time as tragedy, the second time as farce." 

^ See, for exanple, Eliot Freidson, Professional Powers (University of Chicago Press: 

Chicago, 1986), especially. Chapters ("The Question of Professional Decline"). While I do not 
accept Freidson' s definition of profession (for reasons given in 1.3, 1 think his debunking in this 
chapter of the independent-consultant model of professions (and, in general, of the single line of 
development picture of professions) quite useful for freeing up thinking about professions and 
their codes. 

' Gotteri]am\94r96MISC\OPGUIDE. 

^ Kerttrfi Kipnis, "Toward a Code of Ethics for Pre-school Teachers: The Role of the 

Ethics Consultant", Jnternfltional Journal of Applied Philosophy A {Spring 1988): 1-10. 

^ There is some research on "heuristics" that might be relevant Some of this research 

concerns the layout of texts generally, but not applied to codes; some, to corporate codes of 
dMcs (that is, the codes of ethics to be used by en^oyees most of v\tom lack tte education and 
commitment of the typed professional). Such research, though suggestive for design of 
professional codes, is far from definitive. Yet, any claim to know "what works" would, 
presumably, have to rely on such research if it is to have any errprical basis at all. 

'° The exact wording for the ACM is, 'This Code and the supplemental Guidelines were 
developed by the Task Force for the Revision of the ACM Code of Ethics and Professional 
Conduct [with the names following]." The exact wording for the software engineering code is 
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much the same: "This Code was developed by the lEEE-CS/ACM joint task force on Software 
Engineering Ethics and Professional Practices (SEEPP) [with the names following]." 

^^ Email (Gotteibam to Davis), October 27, 1999. 

12 Email (Gotbeatam to Davis), October 27, 1999. 

'^ For a good exanqie of v\tot experts can do, see Wallace C. Koehler and J. Michael 
Pemberton, "A Search for Core Values: Toward a Model Code of Ethics for Information 
Professionals", Journal of Information Ethics 9 (Spring 2000): 26-54. 

' * For exanples of poor advice on writing codes of ethics, see Karim Jamal and Norman E. 
Bowie, "Theoretical Considerations for a Meardngful Code of Professional Ethics", Journal of 
Business Ethics 14 (1995): 703-714. This article is but one in a whole issue on codes of ethics. 
Among these, I found only one that seems to offer good advice (for managers at least): Muel 
Kapein and Johan Wempe, "Twelve Gordian Knots When Developing an Organization Code of 
Ethics" Journfll of Business Ethics 14(1995): 853-69. 

'* Gotiedam has doubts about this recommendation: "Do we really want to repeat the 
nightmare of 4 different ^Dproval processes?" Gottej±)amCh^Dterl2cmt (September 30, 2004). 
That question answers itself. But tte conclusion I draw from that answer is not to use a sinqier 
process for amendment than for original adoption A sinqier method threatens the legitimacy of 
the amendments. The conclusion I draw is that the process of adoption of the original code 
should also be relatively sinple. Adopting a code of ethics should not be a nightmare. 

'^ Margali Sarf'atti Larson, The Rise of Professionalism: A Sociological Analysis (University 
of California Press: Berkeley, 1977), pp. 57-58. 

'' Larson, Rise, p. 6. This appears as a footnote— with an asterisk at her first use of 
"professional project". The footnote is unique in the book; all citations and all other side remaris 
of this sort are given in endnotes. My guess is that the footnote was added at the last minute in 
response to an editor' s concern for what the ordinary reader might suppose. 

" Consider Larson, Rise, again, p. 49: "a successful project of professionalization, one that 
comes close to attaining the goals of market monopoly, social status, and work autonomy, must 
be able to combine certain structural elements." A "code of ethics" is not on her list of "structural 
elements". 

'^ That there is in this story not much evidence of self-interest at work in the debate over 
licensing does not prove that self-interest has no significant part. What the story I tell should do 
is shift the burden of proof Absence of evidence is, after a reasonably diligent search, evidence 
of absence. 

^ ° Even in SEEPF s original (1993) flurry of 29 volunteers, philosophers were as numerous 
as lawyers (with one each, Fodor and Phillips) . 
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^^ The ACM committee had two philosophers (Gotiediam and Johnson) but no lawyer. 

^^ See, for exanqie, Stuart Sh^io, 'Degrees of Freedom The Interaction of Standards of 
Practice and Engineering Judgment", Science, Technology, and Human Values 22 (Summer 
1997): 286-316. 

^^ While this argument seems sound, I should point out that the one perfect stranger we 
interviewed in our backyard, Sigut (v\ten he was in Chicago for a corwention), responded much 
as interviewees we traveled long distances to interview. We had, of course, met him at his 
hotel— and otherwise worked to serve his convenience. Perhaps that explains the similarity 
between that interview and those we did "on site". 

^* The new digital recorders, with memory in gigabytes, may finally have solved this 
problem I say "may" only because I have not yet used one in an interview. Experience with 
other new technologies has taught me to wonder v\tot the hidden disadvantages are. (How, for 
exarrqie, will I save what I have on niy digital recorder in a form recoverable in five or ten 
years— after several changes of format arid technology?) 

^^ There are two exceptions. Steve Barber wrote out his answers in advance. We merely 
discussed them during an interview of over two hours (in a coffee shop on Wall Street), with me 
writing in clarifications as seemed ^Dpropriate. I then sent him the revised interview, v\Mch he 
corrected and approved Dennis Frailey also wrote out his answers in advance— both to the 
original guestionnaire and to supplementary guestions I sent him later. Our interview (in a 
restaurant) still lasted well over two hours, with my notes adding marry details to wtet. he had 
written out in advance. 

^ ^ While I cannot deriy that spontaneous expressions might give insight into the individual 
interviewed and (through lim or ter) into the large context, I have doubts. How does one decide 
when carelessness is only carelessness and v\ten it is something more? Psychology is far from an 
exact science even v\ten a psychologist has weeks or months to evaluate a patient How reliable 
could our judgments be v\ten we had only two hours mostly busy with other matters— and only a 
few words to study later? A spontaneous expression might suggest a hypothesis, but the 
hypothesis would be no more than that without a way to test it How do we test it— except ty 
trying to include the insight in the narrative and seeing whether the narrative seems more 
informative in conseguence? My experience here is that generally, the narrative is no more 
informative in conseguence. 

^ ' Interestingly, there is a disagreement something lite this between the common law and 
dvil law concerning "testimory". For the common law, testimory (ordinarily) consists of the 
oral statement made in court (with documents having to be "read into the record" before they can 
be considered evidence). Even the court transcript is sinqiy a representation of the oral event 
(minus certain inproprieties "stricten from the record"). For the dvil law, on the other hand, 
testimory is (ordinarily) a written document submitted into evidence. Oral testimony in open 
court is more the exception than the rule. 
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Mnutes of SEA meeting of Febmary 7, 2003, p. 4. 



^^ Even if there are academic customs settling how historians or social scientists are to share 
such "raw material", the interviewee would have no idea of them— and it is the interviewee 
whose consent is supposed to be "fully informed". What the protocol does not say can only be 
supposed inqiidt if the ordinary interviewee can reasonably be expected to infer it 

^° The advisory board suggested a very similar interview strategy, for exanple, questions 
such as: 'To v\tot extent was the development of a code profession-oriented? To what extent 
govemment-inposed? And to v\tot extent oriented toward technical education?" (Minutes of 
SEA meeting of Febmary 7, 2003, p. 2.) 

^' Alison Wylie, "Science, Conservation, and Stewardship: Evolving Codes of Conduct in 
Archaeology", Science and Engineering Ethics 5 (July 1999): 319-336. 

^ ^ Sec. 4. 1 does in fact have a "count" (from 1993-94 for SEEPP) and I did count additional 
names from succeeding years (for Gottertem's working group). These total fewer than sixty. 
The problem is that I do not have a complete count for SEEPP or even for the one working group 
that seems to have worked. The reason I do not have either is that no complete list of volunteers 
survives. Even combining all the lists that do survive would not yield a complete list. While 
Gotterbam does not seem to have been trying to "stack the committee", he does seem to have 
continually tried to add to its membership, both in order to have the "right names" associated 
with it and to have help with its work. His record keeping seems not to have been equal to the 
efforts he made to recruit. 

^^ Compare, for example, this question put by J. Barrie Thompson, "Any Real Progress, or 
Is It Just Politics and Turf Wars?" Forum for Advancing Software Engineering Education 11 
(September 15, 2001) http://www.cs.ttu.edu/fase/vlln09.txt: "Why has the project, led by Don 
Gotterbam et al, concerned with defining a Software Engineering Code of Ethics and 
Professional Practice, received such approval and been accepted by bodies outside the US while 
SWEBOK has led to such controversy?" 
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